SHOW_SIMULATION and gated on the
user’s Permissions.prisma / Permissions.fdlive permissions. If your
integration doesn’t expose simulation, skip it.
What you’ll build
- A form for the event fields above.
- Multi-date support — one form, N entries.
- Submit handler that POSTs once per entry.
Prerequisites
- An authenticated user.
X-Preferred-Partner-Idset.- User has
Permissions.prisma(for product events) or fdlive permission.
The call chain
On mount: nothing. The form is purely client-side until submit. On submit (one call per date entry):| Method | URL | Host | Notes |
|---|---|---|---|
| POST | /events/?event_type=prisma|fdlive | CR API | Body = the event payload. No /v3/ prefix. |
Body shape
special_ad_category is only sent when the user selected the “special” tab
in the form (housing / employment / credit / social-issues / etc.).
Reference implementation
/ (the
Dashboard).
Gotchas
CR API host, not main API
CR API host, not main API
POST /events/?event_type=... on the CR API — not /v3/events/ on
the main API. Different host.N POSTs for N dates
N POSTs for N dates
There is no bulk endpoint here. For multi-date entries, one POST per
row. If any fails partway, you have a partial commit — surface this
clearly to the user.
`event_type` is derived from the form mode + permissions
`event_type` is derived from the form mode + permissions
Don’t expose
event_type as a UI knob. Derive prisma from
Permissions.prisma, otherwise fdlive.Error messages are generic in the reference webapp
Error messages are generic in the reference webapp
The reference webapp shows the same
common.errors.inServerResponse
message for all failures and writes the actual error to Sentry. Surface
the real error.<code> to the user instead — it’s more useful.Related
- Event editor — same host, edit flow.
- Bulk event upload — same host, many events.
- CORS & two-host architecture.