API Reference

This section is sourced from the active generated reference set. It is intentionally kept separate from the hand-written guides so implementation details stay close to the code surface they document.

Use this section when you needCopy Anchor Link

• exact method signatures
• event and enum names
• config/interface shapes
• generated class, type, and module pages

For onboarding and task-oriented examples, start with the hand-written guides instead.

Navigation explanationCopy Anchor Link

The reference docs are organized by the surface you are trying to inspect.

• Core covers the primary createClient options and the OpenWAClient interface returned by the embedded runtime.
• Messaging covers shared message, chat, contact, and content shapes used across methods and events.
• Events covers the event map and common event payloads emitted by the runtime.
• Client API Reference contains generated Easy API client method pages. It groups them into namespaces for messages, chats, groups, contacts, media, sessions, status, labels, business, and communities.

Use the top-level reference pages when you need shared types. Use the client sub-sections when you need a specific Easy API method, its route, parameters, aliases, and return shape.

HTTP route conventionsCopy Anchor Link

Client method pages list the primary HTTP route for each method and any supported alias routes. Current Easy API command routes are mounted under /api/.

Method routes follow the schema registry metadata. Namespaced routes use the namespace first, then a short action path, for example POST /api/messages/sendText or GET /api/messages/get. Alias routes keep compatibility with older or direct method names, for example POST /api/sendText.

HTTP methods map to the action being performed:

• GET is used for read and lookup methods.
• POST is used for send, create, update, and command methods with a body.
• DELETE is used for delete methods.

Route segments can use generated names, compatibility aliases, or shorter action names. Treat the listed HTTP route as the preferred route for the current build, and treat HTTP alias routes as compatibility paths when they are shown.

Auth requirementsCopy Anchor Link

Easy API endpoints need the configured API key when the runtime starts with --api-key. Send that key with each request in the X-API-Key header.

curl -X POST http://localhost:8080/api/sendText \
  -H "Content-Type: application/json" \
  -H "X-API-Key: your-secure-key" \
  -d '{"to":"1234567890@c.us","text":"Hello from open-wa!"}'

Some local discovery or health pages can accept a different request shape. Treat command routes as authenticated API calls. If a request returns 401, make sure that the key is present and matches the Easy API process. A 403 means that authentication succeeded, but the endpoint refused the request.

Request body conventionsCopy Anchor Link

Request bodies use JSON objects whose keys match the parameter names listed in each generated method table. For POST and other body-based routes, include Content-Type: application/json and pass the necessary fields shown in the table.

{
  "to": "1234567890@c.us",
  "text": "Hello from open-wa!"
}

Parameter tables also list key aliases and deprecated key aliases when they exist. Prefer the primary parameter name unless you are maintaining older code that already depends on an alias. The Positional parameter order line is mainly useful when comparing HTTP calls with client method calls such as sendText(to, text).

For GET routes with parameters, pass the listed values as query parameters unless the page or generated schema for that method says otherwise.

Generated-reference limitationsCopy Anchor Link

Most client method pages are generated from the active schema registry. That keeps the reference close to the code, but it also means the generated text can have gaps, awkward wording, repeated aliases, or formatting issues.

Use generated pages for exact names, routes, parameter keys, and return shapes. Use the hand-written guides for workflow examples. If a guide and reference disagree, use the reference for the current method surface. Verify it against your runtime version.

ExamplesCopy Anchor Link

Here are a few practical ways to use this section.

Find the route for sending a messageCopy Anchor Link

Open Client API Reference and then Messages. Look for sendText, confirm the listed HTTP route, check necessary parameters, and copy the JSON keys from the parameter table.

Check which object shape an event returnsCopy Anchor Link

Open Events to find the event name and payload type. If the payload includes a message, open Messaging to inspect the shared Message shape.

Compare embedded runtime and Easy API usageCopy Anchor Link

Use Core when you are calling createClient directly in your Node.js process. Use Client API Reference when you are calling a running Easy API instance over HTTP or through SocketClient.

Confirm aliases before changing old codeCopy Anchor Link

Open the generated client method page and check HTTP alias routes, Aliases, and Deprecated aliases. Move new code toward the preferred route and primary parameter names, but keep aliases in mind when maintaining older integrations.