My progress
Menu

Digital Automation · Focus area 3: APIs, webhooks and RevOps

DA7: APIs and webhooks

Goal: connect any system that has an API, even when no ready-made node exists: reading API documentation, making requests with the HTTP Request node, handling sign-in methods, fetching long lists page by page, and receiving webhooks securely.

You'll need: your n8n set-up, the payment workflow from DA6, a test account with a payment gateway such as Razorpay (test mode is enough), and the HTTP basics from Level 4.

Time: reading about 2 hours · practice (the Try it tasks) about 3 hours · assignment about 3 to 4 hours.

Where this is used: ready-made nodes cover popular apps, but many businesses also use a local billing tool, a courier's system or an industry app that offers only an API. The ability to connect "anything with an API" is what separates an automation specialist from someone who only uses templates.

How it differs: a backend developer builds APIs for others to use. An automation builder mostly uses other people's APIs, working from their documentation, their limits and their quirks, and joins several of them into one process.

Lessons

  1. 1Reading API documentationReading 15–25 minutes, plus practice✓
  2. 2Making requests with the HTTP Request nodeReading 15–25 minutes, plus practice✓
  3. 3Signing in to APIsReading 15–25 minutes, plus practice✓
  4. 4Long lists and paginationReading 15–25 minutes, plus practice✓
  5. 5Receiving webhooks securelyReading 15–25 minutes, plus practice✓

🛠️Assignment: The courier and payment connections for Sharma Textiles

This completes the API side of the payment workflow project and adds shipping.

  1. Write API cards for the courier, the payment gateway and the CRM.
  2. Book a test shipment with the HTTP Request node, handling 201, 422 and 429 replies, and save the AWB number.
  3. Record each system's sign-in method, where its secret is kept, and its scopes or permissions.
  4. Fetch all CRM contacts with pagination, a stop rule and a page limit, and check the count against the CRM.
  5. Secure the payment webhook with a signature check and an API confirmation before creating the invoice.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you connect a business system that has an API but no ready-made node?

Show a good answer

A good answer mentions: reading the documentation for base URL, endpoints, methods, auth, fields, errors, limits and test mode, and writing an API card; using the HTTP Request node with the right method, headers, query and body, and reading status codes; choosing the sign-in method and smallest scopes, stored as credentials; fetching long lists with pagination, a stop rule and a page limit; and securing incoming webhooks with the production URL, signature checks and confirmation from the API.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A client says their accounting tool "has an API", and wants invoices created automatically. What should you do before agreeing a price?

Why each option is right or wrong

  • “Agree a price and work out the details while building” (Incorrect): If the API can't create invoices, you'd discover it after promising the work.
  • “Ask the client's salesperson to confirm it will work” (Incorrect): A salesperson's summary isn't a substitute for the technical documentation.
  • “Assume it works like the other accounting tools you know” (Incorrect): Each API differs in what it allows, especially between plans.
  • “Read the API docs for what it allows and on which plan” is correct.

    "Has an API" can mean many things. The docs show whether creating invoices is allowed, which plan it needs, the limits and whether there's a test mode. Finding a gap early lets you suggest an alternative, such as a CSV import, before the client commits.

    • Write: an API card for the tool.
    • Tell the client: any plan or cost implications.

📖 Revise: Lesson 1: Reading API documentation

Question ID sp-digital-automation-07-q1 · Report a mistake in this question
2. Booking a courier shipment returns 422 with "pincode must be 6 digits". The shop sent "110 001". What's the fix?

Why each option is right or wrong

  • “Retry the request with backoff” (Incorrect): A 422 is a data problem; retrying sends the same bad data.
  • “Switch to a courier with a looser API” (Incorrect): The data needs cleaning; another courier would likely want 6 digits too.
  • “Remove the pin code field from the request” (Incorrect): It's a required field; the courier needs it to deliver.
  • “Clean the pin code in the mapping step” is correct.

    The API rejected the value because of the space. Removing spaces (and checking for 6 digits) before the request fixes this order and every future one. Values that still fail can go to review.

    • Then: the reply is 201 Created with an AWB number.
    • Rule: clean at entry, as in DA4.

📖 Revise: Lesson 2: Making requests with the HTTP Request node

Question ID sp-digital-automation-07-q2 · Report a mistake in this question
3. Every request to a CRM returns 404 Not Found. The node calls /v1/contact/123. What's the most likely cause?

Why each option is right or wrong

  • “The CRM is down for maintenance” (Incorrect): Maintenance usually returns 503, and other users would be affected too.
  • “The API key has expired” (Incorrect): An expired key usually returns 401, not 404.
  • “The contact was deleted from the CRM” (Incorrect): That could explain one 404, but not one for every contact.
  • “The URL path is wrong” is correct.

    A 404 on every record points to the address, not the data. The docs show the endpoint as /v1/contacts/123, plural. Copying URLs from the docs avoids small typing slips like this.

    • Add: the correct endpoints to the API card.
    • Test: a GET for one known contact.

📖 Revise: Lesson 2: Making requests with the HTTP Request node

Question ID sp-digital-automation-07-q3 · Report a mistake in this question
4. A marketing tool's connection returned 401 on every call after the person who set it up changed their password. What's the lasting fix?

Why each option is right or wrong

  • “Set Retry On Fail to 10 attempts” (Incorrect): The token was revoked; retries fail the same way every time.
  • “Ask that person to avoid changing their password” (Incorrect): That ties the business to one person's account habits.
  • “Copy the token into the workflow so it can't expire” (Incorrect): Tokens expire or get revoked whatever their location, and copying it into the workflow exposes it.
  • “Reconnect with a shared business account” is correct.

    Changing the password revoked the OAuth tokens tied to that person's login. A business-owned account keeps the connection independent of any one person, and listing it in the credentials file with an owner makes the next issue quicker to fix.

    • Alert: 401 errors go to the credential's owner.
    • Scopes: only what the workflows need.

📖 Revise: Lesson 3: Signing in to APIs

Question ID sp-digital-automation-07-q4 · Report a mistake in this question
5. Connecting a CRM by OAuth, the consent screen asks for "full account access". Your workflows only read contacts and create deals. What should you do?

Why each option is right or wrong

  • “Accept, so future workflows won't need reconnecting” (Incorrect): Convenience later isn't worth the extra risk now; scopes can be added when needed.
  • “Use the CRM owner's personal login instead” (Incorrect): That gives even broader access and ties the connection to one person.
  • “Skip OAuth and paste the CRM admin password into the node” (Incorrect): Passwords in nodes are exposed to anyone who sees the workflow, and admin access is far too broad.
  • “Request only the scopes the workflows use” is correct.

    Asking for read contacts, write contacts and write deals, rather than full access, limits what a leaked or misused token could do. It also makes the client's security review simpler.

    • Record: the scopes in the credentials list.
    • Later: add scopes only when a new workflow needs them.

📖 Revise: Lesson 3: Signing in to APIs

Question ID sp-digital-automation-07-q5 · Report a mistake in this question
6. A monthly sales report shows exactly 100 orders every month, even in October's festive rush. What's the likely problem?

Why each option is right or wrong

  • “The shop limits customers to 100 orders a month” (Incorrect): Shops don't cap total orders like this; the round number points to the report.
  • “Orders after the 100th fail to save in the shop” (Incorrect): The shop dashboard would show the problem; the report is what's capped.
  • “The report's date filter is set to the wrong month” (Incorrect): A wrong month would show different counts, not exactly 100 each time.
  • “Only the first page of results is being read” is correct.

    APIs return long lists a page at a time, often 100 per page. Without pagination the report reads one page and stops. Turning it on with the API's next-page rule and a page limit gives the full list.

    • Check: compare the count with the shop dashboard.
    • October's real figure: 1,240 orders.

📖 Revise: Lesson 4: Long lists and pagination

Question ID sp-digital-automation-07-q6 · Report a mistake in this question
7. You set up cursor-based pagination for a contacts sync. What should you also add?

Why each option is right or wrong

  • “A fixed list of 20 page numbers” (Incorrect): Cursor-based APIs don't use page numbers, and the count varies.
  • “A rule to stop after the first empty field” (Incorrect): An empty field in one contact doesn't mean the list has ended.
  • “Separate workflows for each page” (Incorrect): That's hard to manage and can't know in advance how many pages there will be.
  • “A stop rule and a maximum page count” is correct.

    The stop rule (no next_cursor returned) ends the loop when the list is done. A maximum page count is a safety net in case the rule is wrong, so the workflow can't loop forever or use up the rate limit.

    • Also: a short wait between pages if limits are tight.
    • Check: the total against the CRM's own count.

📖 Revise: Lesson 4: Long lists and pagination

Question ID sp-digital-automation-07-q7 · Report a mistake in this question
8. A payment workflow tested perfectly, but after launch it receives nothing from the shop. The shop was given the URL copied from the Webhook node while testing. What's wrong?

Why each option is right or wrong

  • “The shop needs a paid plan to send webhooks” (Incorrect): Possible in some cases, but the clue is which URL was given.
  • “Webhooks need a few days to start working” (Incorrect): Webhooks start working as soon as the URL and workflow are set up correctly.
  • “The workflow is too long to receive events” (Incorrect): Workflow length doesn't stop a webhook from arriving.
  • “The shop has n8n's test URL, not the production URL” is correct.

    The test URL works only while someone is listening in the editor. Giving the shop the production URL and activating the workflow lets events arrive at any time. Sending a test event from the shop confirms it.

    • Launch checklist: production URL, workflow active.
    • Test: one event from the shop after the switch.

📖 Revise: Lesson 5: Receiving webhooks securely

Question ID sp-digital-automation-07-q8 · Report a mistake in this question
9. Someone who found your payment webhook URL posts a fake "payment captured" event. Which check stops it from creating an invoice?

Why each option is right or wrong

  • “Keeping the URL long and hard to guess” (Incorrect): URLs can be copied or logged; this one has already been found.
  • “Checking that the amount is above zero” (Incorrect): A fake event can contain any amount it likes.
  • “Replying slowly so fakers give up” (Incorrect): Slow replies cause real senders to retry, and don't stop fakes.
  • “Verifying the provider's signature header” is correct.

    The gateway signs each real event with your webhook secret (for Razorpay, the X-Razorpay-Signature header, an HMAC-SHA256 of the raw body). A faker doesn't have the secret, so the signature won't match and the request is rejected.

    • Also: confirm the payment through the API before acting.
    • Log: failed signatures, and alert on repeats.

📖 Revise: Lesson 5: Receiving webhooks securely

Question ID sp-digital-automation-07-q9 · Report a mistake in this question
10. A signed payment webhook passes its signature check. Before sending goods worth ₹48,000, what extra step adds the most safety?

Why each option is right or wrong

  • “Ask the customer to email a screenshot of the payment” (Incorrect): Screenshots are easy to fake and slow the order down.
  • “Wait 24 hours in case the event is withdrawn” (Incorrect): That delays every order and doesn't confirm anything.
  • “Check that the customer's phone number is valid” (Incorrect): A valid phone doesn't confirm the payment.
  • “Fetch the payment from the API and check its status” is correct.

    For high-value orders, confirming with the source adds a second check: the API shows the payment's real status (captured) and amount. If the event and the API disagree, the order goes to review instead of shipping.

    • Also check: the event table and claim (DA6), so repeats are skipped.
    • Compare: amount in paise and order ID.

📖 Revise: Lesson 5: Receiving webhooks securely

Question ID sp-digital-automation-07-q10 · Report a mistake in this question

ProLearners Assist