Skip to main content
POST
cURL
Guide: Applications

Authorizations

Authorization
string
header
required

Authorization: Bearer . An application key (tk_live_, tk_test_) has full access, which covers every product and any product added later, or custom access, chosen when the key is created: one or more of the scopes verify:check, verify:send (includes verify:check), notifications:read, notifications:send (includes notifications:read), email:read, email:send (includes email:read), email:manage (includes email:send), webhooks:manage, email:inbound, notifications:templates (includes notifications:read), chat:menus, chat:attendant. No key made on the API keys page holds notifications:templates, full access included: the three template writes answer such a key 403 insufficient_scope. A connected app's key holds it. Nor chat:menus: the five conversation menu operations answer such a key 403 insufficient_scope, and a connected app's key holds it once the client approved it. Nor chat:attendant: the five auto-attendant operations answer such a key 403 insufficient_scope too, and a connected app's key holds it once the client approved it. email:manage and webhooks:manage are held only by a key someone chose them for: a full-access key, old or new, never holds them. email:inbound, which reads, deletes and forwards received e-mail, is opt-in on every key, full access included: a key holds it only when it was turned on when the key was created. A call outside the key's access answers 403 insufficient_scope and names the scope it needs in the WWW-Authenticate response header. A partner key (tk_partner_) always has full access. Whatever its access, a key is a server-side secret.

Headers

Idempotency-Key
string

A 1 to 128 printable-ASCII key you generate, scoped to your API key. Replaying it with the same request answers the original 2xx unchanged, with the response header Idempotent-Replayed: true, and runs nothing again; the same key with another request answers 409 idempotency_key_reused, and a request still in flight 409 idempotency_in_progress. A refused request is never stored, so a corrected retry under the same key runs. Keys expire after 24 hours.

Body

application/json
external_id
string
required

Your own id for the merchant or store, 1 to 128 characters after trimming. Every later call addresses the application by it, and it is the application value on the Verify endpoints.

name_ar
string
required

The Arabic brand name end users see in their messages, 1 to 80 characters. Screened against protected brands and bait words.

name_en
string
required

The English brand name, 1 to 80 characters. Screened like name_ar.

website
string
required

The merchant's website, an http or https URL. The autofill domain is derived from it (its registrable domain) and is read-only; website_url is accepted as an alias.

industry
string

Free text up to 64 characters, other when omitted. The client console uses ecommerce, fintech, healthcare, education, logistics, saas, marketplace and other.

merchant
object

Your own record of the merchant (a registration number, a contact, a KYC state), stored with the application exactly as given and never validated for shape.

verify
object

Initial verify settings: any subset of the fields of the verify-settings endpoint, the defaults for the rest. A refused value is reported in fields as verify. followed by the field name. Ignored when the application already exists.

metadata
object

Your own tags on the application: up to 20 string values of at most 200 characters under keys of 1 to 40 lowercase letters, digits and underscores. Replaced whole when present, unchanged when omitted, cleared by null or {}; never read by Tawked and not a brand change. A refused key is reported in fields as metadata. followed by the key. The list filters by it.

Response

Already provisioned

service_id
string
application_id
string
external_id
string
status
string
screening
object
verify
object
paused
boolean