An API creates and reads meetings; webhooks tell your systems when something changed. Both are documented requirements on the API and webhooks pages. Design consumers to be idempotent from day one; deliveries can repeat.
Before you start
- A non-production environment and scoped credentials.
- A signature verification step before parsing.
- Event and delivery identifiers stored for de-duplication.
How to complete this task
- Create scoped credentials in a non-production environment.
- Verify webhook signatures before parsing or storing payloads.
- Make consumers idempotent using event and delivery identifiers.
- Exercise retry, delay, duplication, deletion, and version-change cases.
Finish by opening the public link in a signed-out browser: a saved setting is not proof that the guest path works.
Troubleshooting
The problems people report most often with this task, and the cause behind each one.
The same webhook arrived twice.
At-least-once delivery is normal. Consumers must be idempotent on the event identifier — duplicate handling is your responsibility, not the sender's.
Signature verification fails.
Verify against the raw request body before any parsing or re-encoding. Middleware that reformats JSON is the usual cause.
A webhook stopped arriving.
Check whether your endpoint returned errors long enough to be disabled, then replay the missed window rather than assuming the gap is empty.
Related Meetin.gs help
Return to the Meetin.gs Help Center for the adjacent configuration guide, or send the exact event code and expected result when the documented checks do not explain the behavior.
