EntryWick documentation
Partner messages — platform console
Platform console → Operations → Partner messages. Shown once a partner is switched on. The red badge is the number of
messages that could not be delivered. The connection is docs/partners/PLANNERWICK_CONNECTION.md.
Who opens it: support, when a PlannerWick buyer says their plan did not unlock; whoever is on duty when the badge shows. What they came to do: see what EntryWick told the partner about a plan, whether it arrived, and send it again. What must be true when they leave: every message is Sent, or they know why the partner is not answering.
The list
Newest first: when the message was made, the partner, what it says (Activated, Renewed, Cancelled, Payment failed, Plan changed, Ended), the buyer's email and plan, where it stands, how many tries, when the next try is, when it was delivered, and the message id (hidden by default — it is what the partner de-duplicates on).
| Status | Means |
|---|---|
| Pending | Not delivered yet; the next try is at the time shown (1 minute, 10 minutes, 1 hour, 6 hours, 24 hours after each failure) |
| Sent | The partner answered 2xx |
| Failed | Five tries failed; it waits here for Retry now |
The partner's last answer is under the status: the HTTP code and the first words of the body, or "could not reach".
Retry now (owner, finance, support) sends the same message again, with the same id and body, so the partner counts it once however many times it is retried. The retry is on the operators' activity log.
What is sent
One signed POST per change to a plan, to the partner's webhook address, with X-EntryWick-Signature: t=…,v1=… (HMAC
over the time and the raw body with the shared webhook secret). The body is fixed when the message is made; a plan that
changes again gets its own later message. The secret is never shown here or anywhere.
Known limits
- A partner that is switched off, or has no webhook address or secret configured, fails every message immediately (the reason says so) — switch it on and configure it, then Retry.
- There is no bulk retry; after an outage, retry the failed ones one by one, newest first, or wait: a pending one still retries by itself.