The 200-901 exam objective 5.4 asks you to describe the Cisco Webex Teams REST API for messaging and bot integration — this is the bridge that lets software talk to team chat without a human typing every word. Understanding this matters because real IT professionals use APIs to automate notifications, manage collaboration workflows, and build bots that answer questions or trigger actions, which is exactly the kind of hands-on skill the DevNet Associate certification tests.
Jump to a section
A simple way to picture Cisco Webex Teams API and Collaboration
When you send an email to your team asking for project updates, you first get a response from Sarah, then another from Mike, and suddenly your inbox is a tangled mess of replies and forwards. To sort it out, you start an email chain with a clear subject line and keep everyone on the same thread. But if you want to share a file or a quick message without clogging everyone's inbox, you start a separate chat. The Cisco Webex Teams REST API works like that email chain — but it's smarter, faster, and automated.
Now imagine you're the office manager. You don't want to manually email each person every time a new task pops up. Instead, you set up a system: when a task is added to the project board, your system automatically sends a message to the team's Webex space saying, 'New task: Design the homepage mockup.' That's what an API does — it lets one program talk to another without a human in the middle. The 'Webex Teams REST API' is the set of rules and commands that let your code send messages, create spaces, add members, and even listen for new messages, just like you'd use email rules to auto-sort messages into folders. The API replaces the manual effort of opening Webex, typing a message, and hitting send — it does it automatically, thousands of times a day, without error.
The Cisco Webex Teams REST API is a set of programming instructions that allow one piece of software to send commands to the Webex Teams service over the internet. 'REST' stands for Representational State Transfer, which is a style of designing APIs that uses standard web addresses (like URLs) and common commands like GET, POST, PUT, and DELETE. 'API' stands for Application Programming Interface — think of it as a menu in a restaurant: you tell the waiter what you want (the command), and the kitchen (the Webex service) prepares it and brings it back.
At its core, the Webex Teams API lets you automate three main actions: sending messages, managing spaces (which are like chat rooms or group conversations), and controlling membership. For example, if you want a bot to say 'Good morning, team' every day at 9 AM, your code makes an HTTP POST request to the API endpoint https://webexapis.com/v1/messages with a JSON payload containing the room ID and the text. The API then posts that message into the specified space. 'HTTP' is the language browsers and servers use to communicate, and 'JSON' is a lightweight text format for structuring data, like writing a list in a note app but with curly braces and colons.
Why does this exist? Before APIs like this, if you wanted to send a automated message to a chat app, you'd have to simulate a user typing — using clunky scripts that broke when the app updated. The Webex Teams API replaces that fragility with a stable, documented interface. Cisco provides endpoints for everything: creating spaces, listing messages, deleting spaces, adding people, and even getting information about your own account. Each endpoint requires authentication via a token — a secret key that proves your code has permission. This token is passed in the HTTP header of every request.
The API also supports 'webhooks', which are the opposite of sending a message — they let you receive notifications when something happens. For instance, you can set a webhook to send an alert to your server whenever someone posts a message containing 'urgent' in a specific space. This is how bots work: a bot sits on a server, listens to webhook events, and responds automatically. To create a bot, you register it on the Webex for Developers portal, get a unique token, and then write code that processes incoming events via webhooks.
Let's break down the key terms:
Endpoint: A specific URL that does one thing, like 'create a message' or 'list rooms'. Think of it as a door to a specific room in the building of Webex.
Authentication token: A long string of characters that acts like a digital ID card — it tells Webex your code is allowed to do what it's asking.
HTTP methods: GET (read data), POST (create new data), PUT (update existing data), DELETE (remove data).
JSON: The format for sending data, like {'text': 'Hello', 'roomId': 'abc123'}.
Webhook: A way for Webex to call your server when an event happens, rather than you constantly checking.
Cisco Webex Teams API uses the same REST principles as many other APIs, so learning it gives you transferable skills. The official documentation at developer.webex.com lists every endpoint, with examples in multiple programming languages. For the 200-901 exam, you need to know which HTTP method corresponds to which action (for example, POST for creating a message, GET for listing spaces) and how to interpret JSON responses that the API returns. You should also understand the difference between a bot (which uses a bot token and can be added to spaces) and a personal access token (which acts as your own account and can do anything you can do, like read your own messages).
In summary, the Webex Teams API is the tool that lets software talk to people inside a chat app. It replaces manual typing with code, scales from one message to millions, and forms the backbone of modern collaboration automation. For the exam, focus on the lifecycle: authenticate, pick an endpoint, send the correct HTTP method with JSON data, and handle the response.
Obtain an API Token
Go to the Webex for Developers portal (developer.webex.com) and sign in with your Cisco account. If you're building a bot, create a new bot and copy the bot token. If you're using your own account, generate a personal access token from the 'My Apps' section. This token is your digital key — keep it secret, never share it, and treat it like a password. The exam expects you to know that this token goes in the 'Authorization: Bearer <token>' header of every API request.
Identify the Endpoint and HTTP Method
Decide what you want to do: send a message (POST /v1/messages), list spaces (GET /v1/rooms), create a space (POST /v1/rooms), add a person to a space (POST /v1/memberships), or delete a message (DELETE /v1/messages/{messageId}). The exam tests this mapping explicitly — you must know which URL and HTTP verb pair correspond to each action.
Construct the Request
Using your preferred tool (like curl, Postman, or a Python script), assemble the request. Set the URL to the full endpoint (e.g., https://webexapis.com/v1/messages). Add the header 'Authorization: Bearer <your-token>'. For POST and PUT requests, add a 'Content-Type: application/json' header and include a JSON body. For example, to send a message: {'roomId': 'Y2lzY29zcGFyazovL3VzL1JPT00vMTIzNA', 'text': 'Hello from the API!'}. This step is where beginners often mess up — they forget the body or use the wrong field names.
Send the Request and Handle the Response
Execute the HTTP request. The API will send back a response with a status code (200 for success, 201 for creation, 401 for bad token, 404 for missing resource, 429 for too many requests) and a JSON body with the result. Always check the status code — if you get 200, the request succeeded. Parse the JSON to extract useful data like the message ID (to delete it later) or the room ID (to reference in future requests). The exam will ask you to interpret responses, such as identifying which field contains the new message's ID.
Set Up a Webhook for Events
If you want your code to react to new messages automatically, register a webhook. Send a POST request to /v1/webhooks with a JSON body: {'name': 'Message Alert', 'targetUrl': 'https://yourserver.com/webhook', 'resource': 'messages', 'event': 'created'}. The 'targetUrl' must be a public server (use ngrok for testing on your local machine). Whenever someone posts a new message in any space your bot is in, Webex will send a POST to that URL with details about the event. This is how bots become interactive — they listen, then respond using the API in step 3.
Imagine you work as an IT support specialist at a medium-sized company called 'NexGen Ltd', which sells software to other businesses. The support team uses Cisco Webex Teams to communicate internally and with clients. Every day, customers submit support tickets via a web form, and the team has to manually copy the ticket details into a Webex space and notify the right person. This takes 5 minutes per ticket, and with 200 tickets a day, that's over 16 hours of wasted time.
Your manager asks you to automate this. Here's what you do step by step:
First, you go to the Webex for Developers portal (developer.webex.com) and create a bot. You name it 'SupportBot', give it a profile picture, and receive a bot access token — a long secret string that looks like 'NDc1OTUxNjUt...'. You save this securely because it's the key that lets your code act as the bot.
Next, you create a dedicated Webex space called 'Support Tickets — Level 1' and invite SupportBot to that space. The bot now has access to read and write messages there.
You write a small script in Python that runs on a server. This script uses the requests library to call the API. It starts an infinite loop that checks for new support tickets from the web form's database every 30 seconds.
When a new ticket arrives, the script constructs a JSON payload: {'roomId': 'Y2lzY29zcGFyazovL3VzL1JPT00vMTIzNA...', 'text': 'New ticket from Acme Corp: Issue with login, priority High. Assign to Sarah.'}. It then makes an HTTP POST request to https://webexapis.com/v1/messages with the bot token in the header.
The API responds with a JSON confirmation that the message was sent. The script logs this, and the support team sees the notification instantly in the space.
To make it interactive, you also set up a webhook: when someone replies in the space with 'Resolved #123', your server receives that event and updates the ticket status in the database.
This automation saves NexGen Ltd over 15 hours per week. The support team can focus on solving problems instead of typing messages. You also set up a second bot, 'StatusBot', that sends a daily summary message at 8 AM listing open tickets by priority, using the API's ability to create messages on a schedule.
What does an IT professional actually need to know to do this? They need to understand:
How to generate and protect API tokens — if a token leaks, anyone can control your bot.
The difference between a bot token (limited to bot actions) and a personal token (full user access).
The format of API requests: headers (authentication and content type), URL, and body.
How to handle errors: the API returns HTTP status codes like 200 (success), 401 (unauthorised — bad token), 404 (not found), and 429 (rate limit exceeded — too many requests).
How to parse JSON responses to extract data like room ID or message ID.
The concept of rate limiting: you can't send 1000 messages in a second, so you must respect the API's limits (usually 10-30 requests per second depending on the endpoint).
In a more advanced scenario, they might integrate with other tools like ServiceNow or Jira, using webhooks to trigger actions when a ticket is created or resolved. The Webex Teams API becomes the central hub for collaboration automation, replacing manual copy-paste and email chains.
The 200-901 exam tests your understanding of the Cisco Webex Teams REST API in a very specific, predictable way. Expect around 5-8 questions on this objective, primarily in multiple-choice format, but occasionally in drag-and-drop or scenario-based questions. The exam wants you to recall exact endpoint mappings, HTTP methods, and the structure of authentication.
Core exam topics:
Endpoint-to-action mapping: Know that creating a message uses POST to /v1/messages, listing spaces uses GET to /v1/rooms, and deleting a space uses DELETE to /v1/rooms/{roomId}. The exam will give you a scenario like 'You need to list all spaces a bot is part of' and expect you to choose the correct HTTP method and endpoint.
Authentication: You must know that every request to the Webex API requires an 'Authorization' header with the value 'Bearer <token>'. The token can be a personal access token or a bot token. They will test the difference: a bot token is tied to the bot and cannot access user-specific resources like the user's own direct messages.
JSON payload structure: For sending a message, the JSON must contain 'roomId' and 'text' (or 'markdown' for rich text). For creating a space, it requires 'title'. They may present an incomplete JSON and ask you to fix it.
Webhooks: Understand that a webhook has three core components: 'name', 'targetUrl' (your server), and 'resource' (the event type, like 'messages' or 'memberships'). The exam may ask which resource type triggers a webhook when a new message is posted.
Rate limiting and error handling: You'll be tested on standard HTTP status codes. A common trap is confusing 401 (unauthorised) with 403 (forbidden). 401 means missing or invalid token; 403 means the token is valid but doesn't have permission (e.g., a bot trying to access a user's direct messages).
Trap patterns that appear frequently:
The exam will show a URL like 'https://webexapis.com/v1/rooms' and ask which HTTP method creates a new room. Many students mistakenly answer GET because they know GET retrieves data. The correct answer is POST.
They will give a response JSON with extra fields (like 'created', 'modified', 'id') and ask you to identify the field that contains the unique identifier for a room. The correct answer is 'id' (not 'roomId' in the response, though 'roomId' is used in requests).
They may present a scenario where a developer uses a personal token instead of a bot token to automate sending messages in a shared space, and ask why this is bad practice. The answer: personal tokens have full user privileges and can read all user data, creating a security risk. Bot tokens have scoped permissions.
Key definitions to memorise:
REST: Representational State Transfer — a stateless, client-server architecture using standard HTTP methods.
Endpoint: A specific URL for a resource (e.g., /v1/messages).
Token: A secret string used for authentication, passed in the Authorization header.
Webhook: A callback URL that receives HTTP POST requests when an event occurs.
Room/Space: A chat area where members can post messages.
Membership: The relationship between a user and a room (who is in the space).
The exam does NOT test programming syntax deeply — you won't be asked to write Python code. Instead, you'll be given code snippets and asked to identify the correct API call. Focus on the conceptual model: how the API is structured, what each part does, and why it's used. Practise with the official Cisco DevNet sandbox (free) to send real API calls and see responses — this solidifies understanding better than memorising endpoints.
The Webex Teams REST API uses standard HTTP methods — GET to read, POST to create, PUT to update, and DELETE to remove resources like messages and spaces.
Every API request must include an Authorization header with 'Bearer <token>', where the token is either a personal access token or a bot token.
A bot token is scoped to only what the bot needs, while a personal token can do everything your account can do — never use a personal token for a bot.
Creating a message requires a POST request to /v1/messages with a JSON body containing 'roomId' and 'text' (or 'markdown' for rich formatting).
Webhooks are the opposite of an API call — they let your server receive an HTTP POST from Webex whenever a specific event happens, such as a new message in a space.
Each resource in the API has a unique 'id' field in its JSON response — use this ID to reference the resource in subsequent requests, like deleting a specific message.
Rate limits apply: you can typically send 10-30 requests per second depending on the endpoint — exceeding this returns a 429 status code.
The exam focuses on endpoint names, HTTP methods, and authentication — not on programming syntax, so focus on the conceptual model.
API documentation is available at developer.webex.com with live testing tools — use the free Cisco DevNet sandbox to practise real API calls.
A webhook must have a 'targetUrl' that points to a publicly accessible server to receive events — local servers (like your laptop) won't work unless you use a tool like ngrok.
The API can manage spaces (rooms), messages, memberships, and attachments — but not video calls or screen sharing; those require separate SDKs.
JSON responses from the API always include an 'items' array when listing resources (like a list of rooms) — you need to parse that array to find the data you want.
These come up on the exam all the time. Here's how to tell them apart.
Personal Access Token
Tied to a human user account
Can access all user data including direct messages
Expires after 12 hours by default
Bot Token
Tied to a bot application
Only accesses spaces the bot is added to
Does not expire (unless revoked)
GET Request
Used to read or retrieve data
Idempotent: multiple identical calls return same data
Does not create or modify resources
POST Request
Used to create new resources
Not idempotent: multiple identical calls create multiple copies
Requires a JSON body with resource data
API Call (Outgoing)
Developer initiates the request
Pushes data to Webex
Used for sending messages and managing spaces
Webhook (Incoming)
Webex initiates the request to your server
Pulls data from Webex events
Used for receiving notifications and reacting to events
Creating a Room
Uses POST /v1/rooms
Body must include 'title' field
Returns a new room object with an 'id'
Creating a Message
Uses POST /v1/messages
Body must include 'roomId' and 'text'
Returns the new message object with an 'id'
HTTP Status 200
Indicates a successful request
Used for GET requests that return data
Response body contains the requested resource
HTTP Status 201
Indicates a resource was created successfully
Used for POST requests that create something
Response body contains the newly created resource
Mistake
You need to be a programmer to use the Webex Teams API.
Correct
You only need to understand basic HTTP requests and JSON, which you can learn in a weekend. Many IT professionals use no-code tools like Postman to test APIs without writing a line of code.
The term 'API' sounds technical, and beginners assume it requires years of coding experience. In reality, the DevNet exam tests conceptual knowledge, not advanced programming.
Mistake
The Webex Teams API only works with Cisco's own programming language or tools.
Correct
The API is language-agnostic — you can use Python, JavaScript, Java, curl, or even Excel macros to call it, as long as you send valid HTTP requests.
Vendor lock-in is a common fear. Beginners don't realise that REST APIs are a universal standard, not tied to any specific technology from Cisco.
Mistake
If you have a personal access token, you can use it to build a bot that others can add to their spaces.
Correct
A personal access token is tied to your user account and cannot be used as a bot. To create a bot, you must register it on the Webex Developers portal and get a separate bot token.
The term 'token' is overloaded — beginners think all tokens are interchangeable. This leads to confusion when their personal token fails to work in bot scenarios.
Mistake
Webhooks and APIs are the same thing — a webhook is just another way to send a message using the API.
Correct
APIs are for requesting actions (like sending a message). Webhooks are for receiving notifications when something happens (like a new message). They are complementary but opposite directions of data flow.
Both involve HTTP requests, and both start with 'web', so beginners lump them together. Understanding the direction (outgoing vs incoming) is crucial for the exam.
Mistake
The Webex Teams API can directly control video calls and screen sharing.
Correct
The REST API covers messaging, spaces, and memberships only. Video and calling are handled by separate APIs (like Webex Calling API or SDKs for client-side integration). The exam specifically focuses on messaging and bot integration.
Cisco markets 'Webex' as a unified collaboration platform, so beginners assume one API does everything. The exam draws a clear line around what the messaging API covers.
Mistake
Once you send a message via the API, it cannot be deleted.
Correct
You can delete a message using a DELETE request to /v1/messages/{messageId}, as long as the token used is the author of that message or has admin privileges in that space.
In everyday chat apps, you can't always delete messages (or it's limited). Beginners assume the same limitation applies to the API, but it actually has full CRUD (create, read, update, delete) capabilities.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you don't need to install anything. The API works over the internet using standard HTTP requests. You can test it using a browser-based tool like Postman or even a simple curl command in your terminal.
A personal access token acts as you — it can do everything your Webex account can do, including reading all your messages. A bot token is limited to the spaces the bot is added to and can only perform actions the bot is designed for. Always use a bot token for automated scripts.
Yes, you can send a direct message to a user by finding or creating a direct room with that user. Use the /v1/rooms endpoint to list rooms, filter by type 'direct', and then send messages to that room's ID. A bot can do this if added to the user's contact list.
A 401 status code means 'Unauthorised' — your token is missing, invalid, or expired. Check that you have included the 'Authorization: Bearer <token>' header correctly. If you're using a personal token, generate a new one from the developer portal, as tokens expire after 12 hours unless you set them to never expire.
Use the interactive API documentation on the Webex for Developers website. It has a 'Try It' button that lets you send real requests with your token. You can also use Postman, a free tool, or simply type curl commands in your terminal to see immediate responses.
Yes, send a DELETE request to /v1/messages/{messageId} where {messageId} is the 'id' field from the response when you created the message. You must use the same token that sent the message or have admin rights in that space.
Rate limiting means the API will only accept a certain number of requests per second from your token. If you exceed it, you get a 429 status code. For most endpoints, the limit is 10-30 requests per second. You must slow down your requests if you hit this limit.
You've finished Cisco Webex Teams API and Collaboration. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?