Skip to content
AzimeaDocs
Dashboard

Connect your own system

Azimea is not tied to an online shop. Any application, CRM or internal platform can send its people and what they do, and get emails, flows and reports from it.

Azimea does not need an online shop. The store connectors (WooCommerce, PrestaShop and the others) are one way in; the other is your own system: an application, a CRM, a booking or membership platform, a back office, a mobile app’s backend. It tells Azimea who its people are and what they do, and everything else (flows, campaigns, segments, reports, the sending itself) works the same as for a shop. For a short overview without code, see Azimea for apps and digital services.

Your system wants to Use Permission
Keep its people in Azimea, with their own fields and consent Contacts: POST /contacts, or POST /contacts/batch for up to 1,000 at once contacts:write
Say what a person did, so flows start, stop and branch Events: POST /events events:write
Count an action as a result of your emails (an account activated, a plan bought) Mark that event as a conversion in Settings › Events —
Send its own one-off emails (codes, confirmations, alerts) Transactional email through the API, or SMTP if it cannot call an API emails:send
Hear back what happened to those emails Signed webhooks —
Start one specific flow from a script, Zapier or n8n A flow with an API trigger and its own token —
No developer yet Import a CSV file and add events later —

You can start with one piece and add the others when you need them. Give each system its own API key with only the permissions above that it uses.

When you create the account, What kind of business are you? offers An app or digital service. Choose it when you have no online shop: the ready-made flows, the starter emails and the words on screen then talk about users and accounts instead of orders and carts. It is a preset, not a lock; you can change it in Settings › Company and nothing is lost.

Build and test in a sandbox first: its API key sends into the sandbox’s own inbox and reaches nobody.

Example: an onboarding that happens in steps

Section titled “Example: an onboarding that happens in steps”

A person starts a sign-up in your system, has to send some documents, and only then gets an active account. Many stop halfway. Azimea can follow each person through the steps and write to those who stopped.

1. Your system sends an event at each step, with the person in contact:

Terminal window
curl https://api.azimea.com/v1/events \
-H "Authorization: Bearer $AZIMEA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"events": [{
"id": "application-58213-started",
"name": "application.started",
"occurredAt": "2026-10-13T09:30:00Z",
"contact": { "externalId": "client_58213", "email": "alex@example.com", "firstName": "Alex" },
"properties": { "product": "standard", "channel": "web" }
}]
}'

Then documents.submitted when the documents arrive and account.activated when the account is ready. The names are yours to choose (lowercase, with dots); give each event a stable id so a retry is never counted twice.

2. A flow reacts to them. In Flows, create a flow that starts on application.started and, under Stop the workflow when…, stops on documents.submitted:

  • wait one day, then send “You are almost there: the documents we still need”;
  • wait two more days, then send a last reminder;
  • whoever sends the documents leaves the flow at that moment and gets no more reminders.

A second flow on account.activated can welcome them and show the first steps.

3. The result is counted. Mark account.activated as a conversion in Settings › Events. Reports then show how many accounts were activated after an email, per flow and per email.

4. Segments follow. Every event and field you send can be used in segments. For a campaign to everyone who started an application but has no active account yet, pick the segment of people who did application.started and exclude the segment of those who did account.activated.

The rules do not change with where the data comes from: emails go out from your verified domain, consent and unsubscribes are respected, suppressed addresses are skipped, and your plan’s limits apply. Events from your system appear in Settings › Events with their properties, so you can see what arrived before you build on it.