How do I mock the EmailOctopus API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:emailoctopus-style), and run stunt up. You get a local, stateful stand-in for EmailOctopus API 2.0.0 — 21 routes over rest — with no remote account, no network, and no bills.

Is the EmailOctopus API mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of EmailOctopus API (routes, status codes, pagination, webhooks), never real records.

← all adapters

emailoctopus-style

simulates EmailOctopus API 2.0.0

restadapter v0.1.021 routes

verification

VMVM tier — no SDK suite yet· surface 21 · not implemented 2 · differs 3

use it

# add to stunt.yaml
services:
  emailoctopus:
    adapter: embedded:emailoctopus-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the EmailOctopus API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of EmailOctopus API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real EmailOctopus API 2.0.0 surface — the data is fake, the behavior is real.

backing stores

listscontactscampaignsfields

api surface (21)

generated from the adapter manifest — exactly what boots, nothing more

21 routes

GET/lists

POST/lists

GET/lists/{list_id}

PUT/lists/{list_id}

DELETE/lists/{list_id}

POST/lists/{list_id}/fields

PUT/lists/{list_id}/fields/{tag}

DELETE/lists/{list_id}/fields/{tag}

GET/lists/{list_id}/contacts

POST/lists/{list_id}/contacts

PUT/lists/{list_id}/contacts

PUT/lists/{list_id}/contacts/batch

GET/lists/{list_id}/contacts/{contact_id}

PUT/lists/{list_id}/contacts/{contact_id}

DELETE/lists/{list_id}/contacts/{contact_id}

GET/campaigns

GET/campaigns/{campaign_id}

GET/campaigns/{campaign_id}/reports/summary

GET/campaigns/{campaign_id}/reports/links

GET/campaigns/{campaign_id}/reports

POST/automations/{automation_id}/queue

VM-verified behaviors (8)

✓a missing API key is 401 problem+json
✓a blank name is 422 with the field error
✓list create/get round-trip
✓an unknown list is 404 on contact routes too
✓contacts create into the list
✓limit/starting_after paging pages contacts without repeats
✓get by contact id round-trips the email
✓delete removes the contact; reads 404 after

Not implemented (2)

No rate limiting: 429 too-many-requests responses and quotas not simulated
No 403 access-denied, 415 unsupported-media-type, or 405 method problem responses

Differs from the real API (3)

any non-empty bearer token is accepted; real keys are dashboard-issued API keys
contact ids use truncated SHA-256 of the email; the real API uses MD5
v2 has no webhooks; adapter emits unsigned lifecycle events as a local extension

full scorecard →

want more of the EmailOctopus API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.