> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedreach.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Get automation template by ID
> Get an automation template by ID (must belong to authenticated partner)
## OpenAPI
````yaml GET /partner/automation-templates/{id}
openapi: 3.1.0
info:
title: Reach API
version: 1.0.0
description: API documentation for Reach platform
servers:
- url: https://api.embedreach.com
description: Production server
security: []
tags:
- name: Default Partner Resources
x-reach-introduction: >-
---
title: 'Default Partner Resources'
description: 'Convenience endpoints for default resource schemas'
---
Reach provides three default resource schemas that are available to
partners upon request: **customers**, **locations**, and **transactions**.
These schemas come pre-configured with common fields and can be used
immediately once enabled for your partner account.
These default schemas can be customized to match your specific data structure. See [Schema Definitions](/api-reference/endpoint/get-partner-schema-definitions) for information on customizing or creating your own schemas.
## Available Default Schemas
- **customers**: For storing customer/user data
- **locations**: For storing business location data
- **transactions**: For storing transaction/order data
## Using Default Resource Endpoints
The endpoints in this section provide convenient shortcuts for all CRUD
operations on the default resource schemas. These endpoints are equivalent
to using the generic [Partner
Resources](/api-reference/endpoint/get-api-resources-schemadefinitionnameorid)
endpoints with the schema name (`customers`, `locations`, or
`transactions`).
Operations supported:
- **Create**: Single and batch upload
- **Read**: List all resources or get by external ID
- **Update**: Patch single resource or batch patch
- **Delete**: Delete single resource or batch delete
- name: Schema Definitions
x-reach-introduction: >-
---
title: 'Overview'
description: 'Define the shape of your data before you send it'
---
A **schema definition** describes your data as it exists in your system —
a JSON Schema for your customers, transactions, locations, or any custom
record type. These endpoints let you create, read, update, and list those
definitions. Defining a schema is self-service; you don't need to wait on
Reach to do it for you.
**New to this? Read the concepts first — they'll save you a redesign.**
Schema definitions are one half of a two-part model, and the shape you
choose here determines what your tenants can segment and message on later.
- [How Reach models your data](/data-sharing/data-model) — the three
canonical concepts (contact, transaction, location), and the
definition-vs-mapping distinction.
- [Custom Schemas](/data-sharing/custom-schemas) — the JSON Schema format,
`$ref` references between schemas, categories, and PII annotations.
- [Data Sync Setup](/onboarding/data-sync-setup) — how defining schemas
fits into onboarding.
A definition on its own is just a shape Reach stores. To turn it into a
contact, transaction, or location, pair it with a [Schema
Mapping](/api-reference/endpoint/get-partner-schema-mappings).
Validation is strict, and it protects existing data: you can always
**add** fields, but **removing, renaming, or retyping** a field that
resources already use is restricted, and fields that live tenant segments
or merge fields depend on are protected. Iterate freely before go-live; be
deliberate after.
- name: Schema Mappings
x-reach-introduction: >-
---
title: 'Overview'
description: 'Tell Reach how to read your data as its core concepts'
---
A **schema mapping** tells Reach how to interpret your [schema
definitions](/api-reference/endpoint/get-partner-schema-definitions) in
terms of its three canonical concepts — **contact**, **transaction**, and
**location**. It's the step that says "the `email` field on this schema is
the contact's email," "this schema is a `transactions_schema` and
`transactionTotal` is the amount," and so on.
**Definition vs. mapping is the distinction partners most often trip on —
read this before you map.**
- A **definition** is *the shape of your data* (your field names, your
structure).
- A **mapping** is *how Reach reads that shape as its concepts*.
Two steps, two parts of the UI. Start here:
- [How Reach models your data](/data-sharing/data-model) — the concepts
and the definition-vs-mapping split.
- [Custom Schemas → Partner Schema
Mappings](/data-sharing/custom-schemas#partner-schema-mappings) — the full
mapping field reference for contacts, transactions, and locations.
Define your schemas first, then map them. A mapping references a schema
definition by ID, so the definition must exist before you can map it.
- name: Tenants
x-reach-introduction: >-
---
title: 'Overview'
description: 'Create and manage the businesses you serve'
---
A **tenant** is one of your customers — a business you manage on behalf of
your platform. Creating one is the first call you make against the Reach
API: it returns the tenant `id` that every other tenant-scoped call, JWT,
and embedded UI session refers back to.
## Identifying a tenant
A tenant has two identifiers: the Reach `id` returned by **Create
Tenant**, and the `externalId` you supply — your own key for the same
business. **Get**, **Update**, **Delete**, and **Reactivate** each accept
either one in the path, so you never have to store the Reach `id` if you
would rather look tenants up by your own.
## Lifecycle
`POST /partner/tenants` with a name and your `externalId`. Reach provisions the tenant's default resources asynchronously, so some of them appear shortly after the response returns rather than in it.
`PATCH /partner/tenants/{id}` — every field is optional, so send only what changed.
`DELETE /partner/tenants/{id}` deactivates rather than destroys. The tenant drops out of **List Tenants** unless you pass `includeDeleted=true`, and **Get Tenant** keeps returning it with `deletedAt` set.
`POST /partner/tenants/{id}/reactivate` restores a deactivated tenant with its data intact.
## What lives on a tenant
| Field | What it is for |
| --- | --- |
| `name`, `website` | How the business is identified across Reach, and the
site the tracking snippet reports from |
| `locations` | The business's physical addresses |
| `branding` | Logo, colors, brand name, and brand voice — what the
embedded UI and generated content adopt |
| `timezone`, `businessHours` | When the business is open — see below |
| `smsOptInImageUrls` | Evidence of how the business captures SMS consent,
used for carrier registration |
If your partner account is configured with a location schema, the
`locations` you send are stored as location resources rather than on the
tenant record. Reads return them either way, so the field behaves the same
from your side.
### Merged fields and replaced fields
On update, `branding` is **merged** key by key into what is already
stored, so you can send just the keys you want to change. `locations`,
`smsOptInImageUrls`, and `businessHours` are **replaced wholesale** — send
the complete value every time, or you will drop what you left out.
## Listing tenants
**List Tenants** is cursor-paginated through `cursor` and `limit` (default
100). Narrow it with `search`, which matches on name, external id, or
website; order it with `orderBy` and `orderDirection`; include deactivated
tenants with `includeDeleted=true`. For portfolio-wide sweeps, pass
`fields` — a comma-separated projection such as `id,name` — to trim the
payload to what you actually read.
## Timezone and business hours
`timezone` and `businessHours` record when a tenant is open. Both are
accepted on **Create Tenant** and **Update Tenant**, and returned by **Get
Tenant**. They sit on the business itself rather than on any one product,
so one schedule serves every Reach feature that needs it — AI Voice uses
`timezone` today to give the agent the tenant's local time.
You are the source of truth for both. Reach never infers a timezone from a
tenant's address, and an unset value means *not configured* — it does not
mean always open, and it does not mean always closed.
`timezone` is any IANA timezone id — `America/New_York`, `Europe/London`,
`Pacific/Honolulu`. Send `null` to clear it.
`businessHours` is an object carrying all seven weekday keys, `monday`
through `sunday`. Each key is either `null` or an empty list (closed that
day), or a list holding exactly one interval of 24-hour `HH:MM` times:
```json
{
"monday": [{ "open": "09:00", "close": "17:00" }],
"tuesday": [{ "open": "09:00", "close": "17:00" }],
"wednesday": [{ "open": "09:00", "close": "17:00" }],
"thursday": [{ "open": "09:00", "close": "17:00" }],
"friday": [{ "open": "09:00", "close": "20:00" }],
"saturday": [{ "open": "10:00", "close": "14:00" }],
"sunday": null
}
```
Those are local wall-clock times in the tenant's `timezone`, never UTC.
Reach reads them against the tenant's local clock at the instant it
evaluates them, so daylight saving shifts resolve on their own. **The
opening time is inclusive and the closing time is exclusive** — against
`09:00`–`17:00`, a moment at exactly `09:00` counts as in hours, and a
moment at exactly `17:00` does not.
The schedule format is deliberately narrow for now:
- **One interval per weekday.** Split shifts — a midday closure — are not
supported yet.
- **`open` must be earlier than `close`.** An interval cannot cross
midnight, so overnight hours such as `20:00` to `02:00` cannot be
expressed yet.
- **All seven weekdays are required, and an update replaces the whole
schedule.** There is no per-day merge: send every day on each update, and
send `null` for the whole field to clear the schedule.
Tenants can also edit their own timezone and hours from the Voice settings
in the embedded Reach UI. Those edits write to the same business record,
so **Get Tenant** can return values you did not send. Re-read the tenant
if your system needs to stay in sync.
- name: Automation Templates
x-reach-introduction: >
---
title: 'Overview'
description: 'Author automation templates and roll them out to your
tenants'
---
An **automation template** is an automation you define once and sync to
your tenants. Each tenant gets its own automation built from the template.
## Editing steps
A template's steps live in `contents.actionData`. Every step has a
`templateActionId`, which is how a sync matches a template step to the
step it created in each tenant's automation.
| To | Do this |
| --- | --- |
| Edit a step | Send it with its existing `templateActionId`. Tenants'
automations keep the same step, and a message step keeps its communication
group. |
| Add a step | Send it without a `templateActionId`. Reach assigns one. |
| Remove a step | Leave it out of `actionData`. See [Removing
steps](#removing-steps). |
| Reorder steps | Change their `index` values. Steps run in ascending
`index` order. |
Always send back the `templateActionId` you read. A step sent without one
is treated as new, so tenants' automations get a new step in place of the
old one. Each step needs its own `templateActionId`: when you copy a step
to add another, leave the ID out of the copy.
## Removing steps
Removing a step affects customers already in the automation, and adding
the step back doesn't undo it:
- **Customers on the removed step stop.** A customer waiting at a wait
step when a sync removes it stops there with an error. A customer whose
message from a removed step is about to send still receives it, then
stops. Neither continues to the steps that follow. Customers on other
steps are unaffected and continue past the removed step.
- **Adding a message step back doesn't restore tenants' edits.** Once a
sync has removed a message step, adding it back, even with its original
`templateActionId`, gives tenants a new message built from the template.
## Updating a template
`PATCH /partner/automation-templates/{id}` replaces only the fields you
send. Inside `contents`, each field you send replaces the stored one
whole: sending `actionData` replaces the full step list.
A template's `contents.feature` can't change once it's created. A step's
`type` can't change, except between the two wait-until behaviors
(`wait_until_next_occurrence` and `wait_until_next_fixed_time`). To turn a
step into a different kind of step, remove it and add a new one without a
`templateActionId`.
To avoid overwriting someone else's edit, send the `ETag` from **Get
Automation Template** as `If-Match`. If the template was saved after you
read it, the update returns 412 and writes nothing; read it again and
reapply your change.
## Rolling changes out
Saving a template does not update tenants' existing automations. Start a
sync with `POST /partner/automation-templates/{id}/syncs`, then poll `GET
/partner/automation-templates/{id}/syncs/{jobId}` until `status` is
`completed` or `failed`. A finished sync reports `failed` if any tenant
failed; check each tenant's entry in `tenants`.
Some changes reach tenants without a sync:
- **Categories** set with the Automation Template Categories endpoints
apply to tenants' automations right away.
- **Tenants set up later**, such as new tenants on a template in `all`
mode, get the latest saved template.
- **A sync already running** can apply a template saved after it started
to the tenants it hasn't reached yet.
## Choosing tenants
`tenants` sets which tenants receive the template:
| `mode` | Who receives it |
| --- | --- |
| `all` | Every tenant, including tenants created later, except those in
`excludedTenantIds` |
| `selected` | Only the tenants in `tenantIds`. An empty list means none,
which keeps the template a draft. |
A sync deactivates the automation of a tenant that no longer receives the
template, when the automation's current status allows it.
## What a sync changes
- **Trigger settings** are reset to the template's on every tenant
automation that differs, including active ones. Changing a date-based
template's date moves every tenant's scheduled date.
- **Messages a tenant edited** keep the tenant's version. Template changes
to that email or SMS body do not reach them.
- **One-time automations** that are scheduled or already sent are left
unchanged. The sync still reports those tenants as `completed`.
- **Segments** the template uses are created on each tenant, and
reactivated if the tenant deactivated them. A tenant that cannot receive
one of them fails to sync; check its entry in the sync's `tenants`.
paths:
/partner/automation-templates/{id}:
get:
tags:
- Automation Templates
summary: Get automation template by ID
description: Get an automation template by ID (must belong to authenticated partner)
parameters:
- schema:
type: string
required: true
name: id
in: path
responses:
'200':
description: Status 200 response
headers:
ETag:
schema:
type: string
description: >-
Version of the returned template. Send it as If-Match on PATCH
/partner/automation-templates/{id} to update only this
version.
required: true
description: >-
Version of the returned template. Send it as If-Match on PATCH
/partner/automation-templates/{id} to update only this version.
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
message:
type: string
data:
type: object
properties:
template:
type: object
properties:
id:
type: string
format: uuid
name:
type: string
version:
type: string
description: Template version (semver)
visibility:
type: string
enum:
- visible
- hidden
feature:
type:
- string
- 'null'
enum:
- engage
- measure
- reputation
- acquire
- voice
- null
featureSubType:
type:
- string
- 'null'
enum:
- internal-review
- google-review
- post-internal-review
- both-reviews
- null
description: >-
Sub-type that qualifies the template within its
feature, or null when not applicable
contents:
type: object
properties:
name:
type: string
description:
type: string
feature:
type: string
enum:
- engage
- measure
- reputation
- acquire
- voice
triggerType:
type: string
enum:
- one_time
- trigger_based
- date_based
triggerMetadata:
oneOf:
- type: object
properties:
triggerType:
type: string
enum:
- one_time
scheduledAt:
anyOf:
- type:
- string
- 'null'
format: date-time
description: >-
String in ISO 8601 format with timezone
information (e.g.,
"2024-03-20T15:00:00-07:00" or
"2024-03-20T15:00:00Z")
- type: string
enum:
- now
description: >-
Send as soon as the automation is marked
active
- type: 'null'
timezone:
type: string
description: >-
Timezone in IANA format (e.g.,
"America/New_York"). This is used for
auditing and frontend display. Times are
automatically converted to UTC when
stored.
shouldOverrideActiveAutomations:
type: boolean
description: >-
If true, even automations that are
marked active will sync the trigger
metadata (e.g. even if a user turned it
on and it says Jan 1, if you update +
sync to Jan 2, this will override the
active automation and set the date to
Jan 2)
required:
- triggerType
- scheduledAt
- type: object
properties:
triggerType:
type: string
enum:
- trigger_based
eventName:
type: string
description: >-
Name of the event that starts a run.
"USER_ENTERS_SEGMENT" is the only
supported value today, and it is case
sensitive.
eventFilter:
type: object
additionalProperties:
type: string
description: >-
Narrows which occurrences of eventName
start a run, keyed by the event field to
match. For USER_ENTERS_SEGMENT use {
"segment_id": "" }. Use {}
for no filter.
cooldownSeconds:
type: number
description: >-
How long, in seconds, before the same
customer can enter this automation
again. 86400 is one day and 31556952 is
one year. Use 0 for no cooldown, and -1
to never let the same customer enter
again.
artifactOutputKeys:
type: array
items:
type: string
description: >-
Fields copied off the event and handed
to the actions. Use ["userId"], which is
what every automation needs so the
actions know which customer the run is
for.
triggerIdKey:
type: string
description: >-
The field on the event whose value
identifies one run, used to deduplicate.
Use "userId".
customTriggerCopy:
type: string
description: >-
Optional copy to use when displaying the
trigger in the frontend
shouldOverrideActiveAutomations:
type: boolean
description: >-
If true, even automations that are
marked active will sync the trigger
metadata (e.g. even if a user turned it
on and it says Jan 1, if you update +
sync to Jan 2, this will override the
active automation and set the date to
Jan 2)
required:
- triggerType
- eventName
- eventFilter
- cooldownSeconds
- artifactOutputKeys
- triggerIdKey
- type: object
properties:
triggerType:
type: string
enum:
- date_based
monthDayTriggerType:
type: string
enum:
- fixed_date
dayToTrigger:
type: number
description: Day of the month to trigger on
monthToTrigger:
type: number
description: Month to trigger on
customTriggerCopy:
type: string
description: >-
Optional copy to use when displaying in
the frontend
shouldOverrideActiveAutomations:
type: boolean
description: >-
If true, even automations that are
marked active will sync the date (e.g.
even if a user turned it on and it says
Jan 1, if you update + sync to Jan 2,
this will override the active automation
and set the date to Jan 2)
required:
- triggerType
- monthDayTriggerType
- dayToTrigger
- monthToTrigger
actionData:
type: array
items:
oneOf:
- type: object
properties:
templateActionId:
type: string
format: uuid
description: >-
Stable ID of this step. Sync matches
steps by this ID, so tenants'
automations keep their existing step
(and, for messages, its communication
group) when it is unchanged. Omit it to
add a new step; the server assigns one.
index:
type: number
description: >-
Position of the step. Steps run in
ascending index order.
type:
type: string
enum:
- send_communication
html:
type: string
css:
type: string
compiledHtml:
type: string
text:
type: string
subject:
type: string
previewText:
type: string
extraMergeFields:
type: array
items:
anyOf:
- type: object
properties:
id:
type: string
description: The id of the merge field
type:
type: string
enum:
- static
templateName:
type: string
description: >-
The template name of the merge field
(e.g. black_friday_coupon)
displayName:
type: string
description: >-
The display name of the merge field
(e.g. "Black Friday Sale 50% off")
staticValue:
type: string
description: >-
The static value of the merge field
(e.g. "CODE123")
required:
- id
- type
- templateName
- displayName
- staticValue
- type: object
properties:
id:
type: string
description: The id of the merge field
type:
type: string
enum:
- dynamic
mergeFields:
type: array
items:
type: object
properties:
templateName:
type: string
description: >-
The template name of the merge field
(e.g. black_friday_coupon)
displayName:
type: string
description: >-
The display name of the merge field
(e.g. "Black Friday Sale 50% off")
image:
type: object
properties:
placeholderUrl:
type: string
description: The placeholder url of the image
maxSize:
type: number
description: The max size of the image in bytes
required:
- placeholderUrl
- maxSize
required:
- templateName
- displayName
url:
type: string
description: >-
The url to fetch the dynamic merge
fields from
parameters:
type: object
additionalProperties: {}
description: >-
Additional parameters for the dynamic
merge field
required:
- id
- type
- mergeFields
- url
formTemplateKeys:
type: array
items:
type: string
customBlockText:
type: string
reputationTemplateType:
type: string
enum:
- feedback-request
- google-review
- feedback-request-reminder
- google-review-reminder
- combined-request
- combined-request-reminder
required:
- index
- type
- html
- css
- compiledHtml
- text
- subject
- previewText
- type: object
properties:
templateActionId:
type: string
format: uuid
description: >-
Stable ID of this step. Sync matches
steps by this ID, so tenants'
automations keep their existing step
(and, for messages, its communication
group) when it is unchanged. Omit it to
add a new step; the server assigns one.
index:
type: number
description: >-
Position of the step. Steps run in
ascending index order.
type:
type: string
enum:
- wait_until_next_fixed_time
hour:
type: number
minute:
type: number
timezone:
type: string
required:
- index
- type
- hour
- minute
- timezone
- type: object
properties:
templateActionId:
type: string
format: uuid
description: >-
Stable ID of this step. Sync matches
steps by this ID, so tenants'
automations keep their existing step
(and, for messages, its communication
group) when it is unchanged. Omit it to
add a new step; the server assigns one.
index:
type: number
description: >-
Position of the step. Steps run in
ascending index order.
type:
type: string
enum:
- wait_until_next_occurrence
hour:
type: number
minute:
type: number
timezone:
type: string
required:
- index
- type
- hour
- minute
- timezone
- type: object
properties:
templateActionId:
type: string
format: uuid
description: >-
Stable ID of this step. Sync matches
steps by this ID, so tenants'
automations keep their existing step
(and, for messages, its communication
group) when it is unchanged. Omit it to
add a new step; the server assigns one.
index:
type: number
description: >-
Position of the step. Steps run in
ascending index order.
type:
type: string
enum:
- wait_for_duration
days:
type: number
minimum: 0
default: 0
hours:
type: number
minimum: 0
default: 0
minutes:
type: number
minimum: 0
default: 0
seconds:
type: number
minimum: 0
default: 0
required:
- index
- type
- type: object
properties:
templateActionId:
type: string
format: uuid
description: >-
Stable ID of this step. Sync matches
steps by this ID, so tenants'
automations keep their existing step
(and, for messages, its communication
group) when it is unchanged. Omit it to
add a new step; the server assigns one.
index:
type: number
description: >-
Position of the step. Steps run in
ascending index order.
type:
type: string
enum:
- check_segment_membership
segmentIds:
type: array
items:
type: string
required:
- index
- type
- segmentIds
includeSegmentDefaults:
type: array
items:
anyOf:
- type: object
properties:
id:
type: string
name:
type: string
description:
type: string
conditions:
type: array
items:
anyOf:
- $ref: >-
#/components/schemas/SegmentFieldCondition
- type: object
properties:
sql_segment_id:
type: string
required:
- sql_segment_id
- $ref: >-
#/components/schemas/RelatedResourceCondition
required:
- id
- name
- description
- conditions
- type: string
enum:
- all_users
- type: string
format: uuid
description: Partner segment definition ID
excludeSegmentDefaults:
type: array
items:
anyOf:
- type: object
properties:
id:
type: string
name:
type: string
description:
type: string
conditions:
type: array
items:
anyOf:
- $ref: >-
#/components/schemas/SegmentFieldCondition
- type: object
properties:
sql_segment_id:
type: string
required:
- sql_segment_id
- $ref: >-
#/components/schemas/RelatedResourceCondition
required:
- id
- name
- description
- conditions
- type: string
enum:
- all_users
- type: string
format: uuid
description: Partner segment definition ID
priority:
type: number
usePointOfContactSender:
type: boolean
senderProfileId:
type:
- string
- 'null'
format: uuid
required:
- name
- description
- triggerType
- triggerMetadata
- actionData
- includeSegmentDefaults
tenants:
oneOf:
- type: object
properties:
mode:
type: string
enum:
- all
excludedTenantIds:
type: array
items:
type: string
format: uuid
description: >-
Tenants left out. Tenants created later
still receive the template.
required:
- mode
- excludedTenantIds
- type: object
properties:
mode:
type: string
enum:
- selected
tenantIds:
type: array
items:
type: string
format: uuid
description: >-
The only tenants that receive the
template. [] = none (draft).
required:
- mode
- tenantIds
description: Tenants the template is synced to
createdAt:
type:
- string
- 'null'
updatedAt:
type:
- string
- 'null'
required:
- id
- name
- version
- visibility
- feature
- featureSubType
- contents
- tenants
- createdAt
- updatedAt
required:
- template
required:
- success
'400':
description: Bad Request - Validation or request error
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
enum:
- false
default: false
message:
type: string
description: Error message describing what went wrong
errors:
type: array
items:
type: string
description: Optional array of specific validation errors
required:
- message
components:
schemas:
SegmentFieldCondition:
type: object
properties:
type:
type: string
enum:
- property
field:
anyOf:
- type: string
enum:
- userId
- email
- phone
- firstName
- lastName
- hipaaConsent
- type: string
value:
type: array
items:
anyOf:
- type: string
- type: number
- type: boolean
- type: string
format: date-time
- $ref: '#/components/schemas/SegmentRelativeDate'
- $ref: '#/components/schemas/SegmentBetweenDate'
description: >-
The value to compare the field against (string, number, boolean,
date)
operator:
type: string
enum:
- equals
- not_equals
- greater_than
- less_than
- exists
- not_exists
- equals_month_day
- equals_month_day_year
- between_month_day
- between_month_day_year
- array_contains
- contains
- not_contains
- in
description:
type: string
description: Optional human-readable note describing this clause
required:
- field
- value
- operator
RelatedResourceCondition:
type: object
properties:
type:
type: string
enum:
- related_resource
relatedResource:
$ref: '#/components/schemas/SegmentRelatedResource'
countOperator:
type: string
enum:
- eq
- gt
- gte
- lt
- lte
countValue:
type: integer
minimum: 0
aggregate:
$ref: '#/components/schemas/SegmentRelatedResourceAggregate'
description:
type: string
conditions:
type: array
items:
anyOf:
- $ref: '#/components/schemas/SegmentFieldCondition'
- $ref: '#/components/schemas/RelatedResourceCondition'
required:
- type
- relatedResource
- countOperator
- countValue
- conditions
description: >-
Query the subject by its related resources. Nests at most 4 relationship
hops.
SegmentRelativeDate:
type: object
properties:
type:
type: string
enum:
- relative
value:
type: integer
minimum: 0
description: Number of date units to add/subtract from today
unit:
type: string
enum:
- days
- months
- years
direction:
type: string
enum:
- before
- after
required:
- type
- value
- unit
- direction
SegmentBetweenDate:
type: object
properties:
startDate:
anyOf:
- type:
- string
- 'null'
format: date-time
- $ref: '#/components/schemas/SegmentRelativeDate'
- type: 'null'
endDate:
anyOf:
- type:
- string
- 'null'
format: date-time
- $ref: '#/components/schemas/SegmentRelativeDate'
- type: 'null'
required:
- startDate
- endDate
SegmentRelatedResource:
type: object
properties:
schemaId:
type: string
foreignKeyPath:
type: string
foreignKeyOn:
type: string
enum:
- current
- linked
required:
- schemaId
- foreignKeyPath
SegmentRelatedResourceAggregate:
type: object
properties:
function:
type: string
enum:
- sum
- avg
- min
- max
field:
type: string
minLength: 1
operator:
type: string
enum:
- eq
- gt
- gte
- lt
- lte
value:
anyOf:
- type: number
- $ref: '#/components/schemas/SegmentRelativeDate'
required:
- function
- field
- operator
- value
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.