API and Webhooks

Seedly CRM exposes a public REST API and a webhook system so you can integrate with other tools, push events in, and receive events out.

---

REST API#

A versioned REST API at /api/v1 lets external systems read and write your CRM data.

• Authenticated with API keys you create in settings, passed as a bearer token
• Scoped permissions per key (for example, read-only contacts, or read and write conversations) so a key can only do what you allow
• Agency-level keys can act across sub-accounts by naming the target sub-account on the request; sub-account keys are scoped to one
• Test and live keys, and the ability to revoke or expire a key at any time
• Resources include contacts, conversations and messages, calendars and appointments, verified customer booking, opportunities, pipelines, tasks, campaigns, sub-accounts, and webhook subscriptions
• Opportunities and tasks are full read and write resources, not just webhook events. Opportunities have dedicated endpoints for moving stage and setting status so a change fires the right automation. Pipelines are read-only
• Invoices are the one notable gap. There is an invoice.paid event to subscribe to, but no invoice endpoints. Because you own the source, adding one is a documented pattern in the API guide
• Consistent response envelope and clear error codes, with a machine-readable spec
• Because you own the source, you can add your own endpoints next to the built-in ones using the same auth, scope, and rate-limit helpers. See the REST API reference

Booking, for an AI assistant#

There is a separate group of endpoints for an outside booking service, so it can run a booking conversation end to end without being handed your whole schedule. This is the surface you point something like an AI setter at.

• Ask what you sell and what it costs, so the assistant can answer "what does a drain clean run" instead of saying it does not know
• Ask what times are open, reading your real availability rather than a guess
• Look up, move, or cancel one caller's own appointment, for that caller only

The last group is the one worth understanding. Until recently the only way an outside integration could see what somebody had booked was the permission that returns your appointment roster, and that roster carries every customer's name, email, and phone and needs no date range. Handing a booking service enough access to cancel one visit meant handing it your customer list.

Now it does not. The caller proves who it is speaking for, either with the contact id your CRM issued or with two matching details, and gets that person and nobody else. A last name on its own is never enough.

Two things are deliberate and worth knowing before you build against it:

• Every wrong combination returns the same answer. A wrong phone with a right email, a customer who does not exist, and a customer with nothing booked all read identically. If they did not, somebody could confirm one of your customers' email addresses one request at a time
• A repeating booking is refused and your team is notified. "Cancel my appointment" against a weekly service might mean this Thursday or the whole arrangement, and an assistant on a call cannot know which, so a person decides

There is also a shorter read that returns only the appointments a customer can still act on. Point your assistant at that one before it cancels or moves anything: given a full history, an assistant will sometimes pick a record that was cancelled months ago and then tell the customer their real appointment could not be changed.

Endpoints an add-on can contribute#

Add-ons install into your CRM and can bring their own API endpoints with them. They authenticate the same way, carry their own permissions on the same key form, and use the same response envelope and rate limits as everything else. The add-on decides only the shape of the data it returns.

GET /api/v1/ext lists what is installed and the permission each contributed route needs, so an integration can discover them rather than being told.

Inbound Webhooks#

Inbound webhooks let an external system trigger your automations.

• Each workflow can expose an inbound webhook URL; an HTTP POST to it injects a custom event and runs the workflow
• Useful for connecting tools that are not built-in, for example firing a workflow from a third-party form, a payment processor, or your own app

Outbound Webhooks#

Outbound webhooks push CRM events to a URL you control.

• Subscribe to events such as a contact created, a message received, an appointment booked, an invoice paid, and more
• Each delivery is signed so you can verify it came from your CRM, and includes the sub-account it belongs to
• The community platform can also send events in (for example a chat message or a recorded payment) to trigger CRM workflows

For the full endpoint reference, request and response shapes, scopes, and event payloads, see the published integration guide and webhook reference linked from your help site.