Template config

GET https://www.ewyn.ai/api/v1/templates/config

Example#

curl https://www.ewyn.ai/api/v1/templates/config \
  -H "Authorization: Bearer $EWYN_API_KEY"

Response#

A map keyed by template name, slugified (lowercase, spaces become hyphens, other punctuation is dropped). Each template lists its latest major version and all non-deprecated versions with their variable requirements:

{
  "welcome": {
    "name": "Welcome",
    "latest": 2,
    "versions": {
      "1": {
        "id": "version-uuid-1",
        "vars": {
          "firstName": { "required": true },
          "plan": { "required": false }
        }
      },
      "2": {
        "id": "version-uuid-2",
        "vars": {
          "firstName": { "required": true },
          "ctaUrl": { "required": true }
        }
      }
    }
  },
  "password-reset": {
    "name": "Password Reset",
    "latest": 1,
    "versions": {
      "1": { "id": "version-uuid-3", "vars": { "resetUrl": { "required": true } } }
    }
  }
}

If two templates share a slug — say a “Welcome” template in two different folders — the one created first keeps the plain key and each later one gets the first 8 characters of its template ID appended, e.g. welcome-3f9c2a1b. Keys only change when a collision appears, so templates with unique names keep the same key.

What it's for#

• Feed it to the SDK's templates option for name-based, compile-time-checked sending — the fetch-config CLI wraps this endpoint and writes a ready-to-import TypeScript file
• Resolve a template name + version to the templateVersionId the send endpoint expects
• Validate at deploy time that every variable your code passes is one the template actually uses