Developer Guide Overview

Overview

API keys, authentication, REST resources, contacts, business events, webhooks, signatures, retries, errors, and logs

Chapter purpose

This chapter provides server-side guidance for authorized developers connecting websites, ecommerce, CRM, ERP, LMS, POS, payment, and internal systems with Wemblo.

Chapter contents

1. Developer Guide Overview
2. Create, Restrict, Rotate, and Revoke Wemblo API Keys
3. Authenticate REST API Requests
4. REST API Resources and Request Patterns
5. Create and Update Contacts through the API
6. Connect Messages, Forms, Campaigns, and Business Events
7. Configure Wemblo Webhook Subscriptions
8. Verify Webhook Requests and Signatures
9. Handle Retries, Duplicate Events, and Idempotency
10. Understand Rate Limits and Errors
11. Review API and Webhook Logs
12. API and Webhook Troubleshooting

INTEGRATION DIRECTIONS

REST API: The external system requests or updates a documented Wemblo resource.

Wemblo Outbound Webhook: Wemblo sends a subscribed event to the customer's HTTPS endpoint.

Incoming Business Event: The external system sends an order, payment, booking, or other supported event into Wemblo.

Provider Webhook: Meta, payment, or another provider sends events to Wemblo. Do not confuse these directions.

DEVELOPMENT PRINCIPLES

• Use HTTPS and server-side code.
• Use a separate key for each system or environment.
• Grant the minimum required scopes.
• Never expose a key in browser JavaScript, distributed mobile code, screenshots, or public repositories.
• Validate requests and responses.
• Use idempotency for create and payment-like actions.
• Log request IDs and redacted errors.

Who should use it

Authorized developers and technical workspace users.

Before you begin

• Use a server-side integration environment.
• Create separate test and production credentials.
• Use HTTPS and least privilege.
• Never expose a key or webhook secret in client-side code.

Main concepts and fields

Test and verification

1. Complete one successful path with fictional data.
2. Complete one invalid, failure or permission path.
3. Confirm the result appears in the correct workspace and module.
4. Confirm the correct person or team can review and continue the work.

Common issues and solutions