Platform

Morasel API for developers

Read and act on the same records your team uses — conversations, customers, appointments, orders — with tokens you scope, restrict by IP and expire on your own schedule.

Why an unscoped, undated key is a liability

A single API key with no scope, no IP restriction and no expiry is a standing risk: if it leaks, whoever finds it can read or write anything the workspace can. Most integrations need a fraction of that access, for a fixed period, from known systems.

  • A token with full access can read or write records an integration never needed.
  • A token with no expiry is still valid a year after the project that created it ended.
  • A token usable from any IP address can be replayed from anywhere the plaintext leaks to.
  • A key nobody can find the plaintext of again cannot be checked, only revoked and replaced.

What Morasel records for each token

One token record per integration, so an owner can see what it can do and when it was last used without asking the team that built it.

Token name
The label your team gives the token, tied to the integration it belongs to.
Prefix
The first characters of the token, shown after creation so it can be identified without the secret.
Scopes
The objects and actions the token can reach; read access by default, write scopes granted per object.
IP allow-list
Up to 20 addresses the token can be used from; empty means no IP restriction.
Expiry
A date up to 365 days out after which the token stops working.
Last used
The most recent time a request authenticated with this token.
Webhook endpoint
The URL and signing secret you register from the workspace for your integration.

From creating a token to rotating it

The plaintext secret exists once, at creation. Everything after that runs on the prefix and the scopes you set.

  1. Create a token (owner)

    Name it, choose its scopes, optionally set an IP allow-list and an expiry of up to 365 days.

  2. Copy the secret once

    The full token is shown a single time. After that, only its prefix is visible on the record.

  3. Call the REST API with a Bearer header

    Authenticate requests against the documented endpoints; each call is checked against the token's scopes and IP allow-list.

  4. Register a webhook endpoint and keep its signing secret

    Add the endpoint URL from the workspace and store the signing secret it gives you.

  5. Rotate: create the successor, revoke the old one

    Issue a new token before the old one expires or is compromised, then revoke the old one once the new one is live.

What the customer sees

A message sent through the API looks exactly like one sent from the workspace — the customer has no way to tell which.

What your team sees

Token activity is a record, not a mystery in the logs.

  • Every token's scopes, IP allow-list, expiry and last-used time, on one record.
  • The webhook endpoint and the option to reveal or rotate its signing secret.
  • A prefix to identify a token in conversation without ever needing the secret again.
  • Creation and revocation events on the same audit trail as everything else in the workspace.

Who can do what

Issuing and revoking access is kept to the people who own the workspace, and every change is recorded.

  • Only a workspace owner can create or revoke an API token.
  • Scopes default to read; write access to an object is granted explicitly, not assumed.
  • An IP allow-list, when set, limits a token to up to 20 known addresses.
  • Every token creation and revocation is in the audit log, with who did it and when.

What Morasel does not do

Webhook endpoints are registered with a signing secret from the workspace. Morasel does not publish SDKs; the REST API is documented as OpenAPI. Registering an endpoint stores its URL and signing secret for your integration.

Start building on Morasel

Create a workspace, issue a scoped token, and read the OpenAPI reference for the endpoints you need.

Developer questions

How do I get a token?

A workspace owner creates it from the workspace: name, scopes, and optionally an IP allow-list and an expiry. The plaintext is shown once at creation.

What scopes exist?

Read access is the default. Write access to a specific object — conversations, customers, appointments, orders — is granted per scope, so a token only reaches what it was built for.

What does the IP allow-list do?

It restricts the token to up to 20 specific IP addresses. Leave it empty and the token works from anywhere the secret is used; set it and requests from other addresses are rejected.

How long can a token last?

Up to 365 days. After that, or on the date you set, it stops authenticating and needs to be replaced.

Where is the API reference?

The REST API is documented as OpenAPI at /docs, covering the endpoints a token's scopes can reach.