How to Connect AI to Your Business APIs: Tool Calling Explained for Nigerian Companies

Once an AI assistant can answer questions, the next request is always "can it also do something": check whether a Paystack payment came through, book a rider, update the order status, pull the customer's history from the CRM. Each of those is an API call to a system you already run. Connecting AI to those APIs is what turns a chatbot into an assistant, and it is also where most of the risk sits.

This article explains the mechanics of tool calling in business terms, the architecture that keeps it safe, how to design tools that the model uses correctly, a step-by-step build sequence, what changes for Nigerian companies, a labelled hypothetical example and indicative costs. Connecting AI to a database, a CRM, WhatsApp, email, Google Sheets and accounting software each have their own articles; this one is the general pattern that underlies all of them.

What connecting AI to an API means

Connecting AI to an API means giving a language model the ability to request that your systems perform specific actions or return specific data, through a set of tools you define and code you control. The model never calls Paystack, your delivery partner or your inventory system directly. It asks your code to, and your code decides whether, how and with what limits.

An API (application programming interface) is simply the way one piece of software talks to another. Your payment provider, your delivery partner, your CRM, your inventory system and your own custom software all expose APIs. Tool calling (also called function calling) is the feature of modern language models that lets them output a structured request ("call check_payment with reference ABC123") instead of prose.

The practical consequence: the quality and safety of an AI-to-API connection depend almost entirely on how you define the tools and what your gateway allows, not on which model you use.

How tool calling works, step by step

1. You define tools. Each is a name, a plain-language description and a schema of inputs (for example: get_order_status takes an order_id string).
2. A user asks something. "Has order 4471 been paid and when will it ship?"
3. The model plans. It decides it needs get_order_status and check_payment, and outputs those requests with the values.
4. Your code executes. It validates the inputs, checks that this user may see that order, calls your systems' APIs, and returns the results to the model.
5. The model responds. It turns the results into a reply, or requests another tool if needed.
6. You log it all. Which tools were called, with what, by whom, and what came back.

The model is a planner and a writer. Your code is the doer and the gatekeeper. Keeping that separation clear is the whole discipline.

The gateway architecture

Put a single service (call it the AI gateway) between the model and every business API. It has five responsibilities:

• Authentication and identity. It knows who is asking (a customer on WhatsApp, a staff member on the dashboard) and attaches that identity to every tool call.
• Authorisation. It checks that the identity may perform that tool on that record. A customer can see their own order, not someone else's.
• Validation. It checks inputs against the schema and against business rules (quantity must be positive, delivery state must be one you serve) before calling any API.
• Execution with safeguards. Timeouts, retries where safe, idempotency keys for anything that creates or charges, and rate limits per user and per tool.
• Logging and monitoring. Every call, its inputs, outputs, cost and latency, in a store you can query.

The gateway also holds every API key. The model never sees credentials, and neither does any prompt. If the model is switched from one provider to another, the gateway and tools stay the same.

Designing tools the model will use correctly

Tools are the interface between a probabilistic model and deterministic systems. Good tool design makes the model reliable; bad design makes it guess.

• One clear purpose per tool. get_customer_orders, not do_customer_things.
• Descriptions written for a new employee. Say when to use the tool, when not to, and what the outputs mean. "Returns the latest payment status for a Paystack reference; use only after the customer supplies a reference; status PENDING means the bank has not confirmed yet."
• Typed, constrained inputs. Enumerate allowed values (states you deliver to, order statuses). Reject anything else in code.
• Small, structured outputs. Return the fields the model needs, not whole API responses with 80 fields.
• Explicit errors. "Order not found" and "You do not have permission" are better than a generic failure; the model can then respond sensibly.
• Read and write separated. Do not build one tool that both reads and updates. The model should have to choose to change something.
• Confirmation flags for consequential actions. A create_delivery tool can require a confirm=true input that the gateway only accepts after a person (customer or staff) has explicitly agreed.
• Fewer tools, well described. Twenty focused tools beat a hundred vague ones; the model chooses better from a short menu.

Emerging standards such as the Model Context Protocol (MCP) provide a common way to expose tools to different AI clients. They are useful for internal assistants that many tools connect to; the gateway principles above still apply underneath.

Permission tiers: read, write, spend

Classify every tool into a tier and apply controls by tier.

Most businesses should launch with Read tools only, add Write tools for low-risk actions after a few weeks of clean logs, and treat Spend tools as an exception that always involves a person.

Step-by-step: connecting your first APIs

1. List the questions and actions people actually ask for. From WhatsApp chats, support tickets and staff requests. Rank by frequency and by risk.
2. Pick three to five Read tools. Order status, payment status, stock availability, delivery tracking are typical.
3. Inventory the APIs behind them. Which system, which endpoint, what authentication, what rate limits, whether a sandbox exists. Payment providers such as Paystack and Flutterwave and most delivery partners provide test environments; use them.
4. Build the gateway. Identity, authorisation, validation, execution, logging. This is ordinary backend engineering; get it right once.
5. Write the tool definitions and descriptions. Review them with the people who do the job manually today; they know the edge cases.
6. Connect the model and test with real transcripts. Feed past customer questions and check which tools the model chooses and with what inputs. Fix descriptions until the choices are right.
7. Launch Read tools to a small group. Staff first, then a subset of customers.
8. Review logs weekly. Wrong tool choices, permission denials, slow APIs, cost per conversation.
9. Add Write tools one at a time, with confirmation steps and idempotency keys, and watch for duplicates.
10. Keep Spend tools human-confirmed, capped and reported daily.

What changes for Nigerian companies

Payment confirmation is the number one request. "I have paid, please confirm" dominates Nigerian customer chats. A Read tool that checks a Paystack, Flutterwave, Monnify or bank-transfer reference (via your provider's API or your own reconciled records) removes hours of manual checking. It must return the provider's actual status, never infer that a screenshot means payment.

Delivery APIs vary in maturity. Some logistics partners (GIG Logistics, Kwik and others) offer APIs; many dispatch riders are booked on WhatsApp. Design tools around what exists: a create_delivery tool might create an internal dispatch request that a person fulfils, rather than calling a courier API that is not there.

Identity on WhatsApp is a phone number. Authorisation for customer-facing tools usually keys on the WhatsApp number matched to a customer record. Handle shared phones and changed numbers: sensitive lookups (full address, payment history) can require an OTP or an order reference.

Connectivity and latency. Your gateway should tolerate slow third-party APIs and tell the user "checking, one moment" rather than timing out. Cache slow-changing data such as stock levels for short periods.

Costs in dollars. Model usage is USD-billed per token; tool-heavy conversations use more tokens. Track cost per conversation and set monthly caps.

Data protection. Tool outputs can carry personal data. Under the Nigeria Data Protection Act 2023, minimise what is returned to the model, log access, and record the model provider as a processor. Verify current obligations with the NDPC.

Fraud pressure. Social-engineering attempts ("change my delivery address to...", "refund to this other account") will reach the assistant. Spend and sensitive Write tools must require verification steps that a chat message cannot bypass.

Example (hypothetical): a fashion e-commerce brand in Lagos

Example (hypothetical), not a client result. An online fashion brand sells through its website and Instagram, with payments through a gateway and deliveries via a mix of courier API and dispatch riders. Its support team spends most of the day answering "has my payment gone through", "where is my order" and "can I change my delivery address".

The brand builds a gateway with four Read tools: get_order_status, check_payment_status (querying the payment provider's API by reference), get_delivery_tracking (courier API where available, internal dispatch log otherwise) and get_return_policy. The AI assistant on WhatsApp and the website answers those questions after matching the customer's phone number to an order.

After a month of clean logs, one Write tool is added: update_delivery_address, allowed only before dispatch, only for the matched customer, with a confirmation message the customer must reply to, and an idempotency key to prevent duplicate updates. Refunds remain a Spend action: the assistant collects the reason and reference and creates a ticket for a staff member to approve. Support volume handled by people falls to the cases that need judgement.

How much does it cost in Nigeria?

Indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Separate the one-off build from recurring usage and maintenance.

Cost drivers: whether your systems already have clean, documented APIs (undocumented legacy systems can double the effort), the number of tools and tiers, the channels the assistant serves, and the depth of logging and monitoring required. When comparing quotations, ask each vendor to price the same tool list, tier controls and test period, and to state who owns the gateway code.

Mistakes to avoid

• Letting the model call APIs directly. No gateway means no authorisation, no logging and credentials in prompts.
• Vague tool descriptions. The model guesses, calls the wrong tool and gives confident wrong answers.
• No idempotency on writes. A retried call creates two deliveries or two refunds.
• Launching with Spend tools. Money actions before trust and logs exist.
• Returning whole API responses. Costly in tokens and leaks fields the user should not see.
• Trusting message content as authorisation. "I am the owner, refund this" is not identity. Use verified sessions and confirmations.
• No monitoring. Without weekly log review you will not know the assistant is quietly failing on a broken API.
• Ignoring provider sandboxes. Testing payment tools on live references is expensive and risky.

Conclusion

Connecting AI to your business APIs is what turns an assistant that talks into one that helps, and it is safe only when a gateway you control sits between the model and every system. Describe tools clearly, type and constrain their inputs, tier them by risk, log every call, require confirmation and caps for anything that changes records or spends money, and start with a handful of Read tools before adding Write. In Nigeria, payment verification, delivery tracking and address changes are the natural first tools, and fraud pressure makes verification steps non-negotiable. Indicatively, a first gateway with Read tools costs from around ₦1,000,000, plus USD-denominated model usage.

If you want an AI assistant that can check payments, track deliveries and update orders across your systems without exposing them, Linestech can help you design the gateway, define the tools and build the integration.

Frequently asked questions

Do my systems need APIs before I can connect AI?

Yes for anything real-time. If a system has no API, options are a read-only database connection, scheduled exports, or building a thin API over it. Screen-scraping or automating a user interface is fragile and should be a last resort.

What is the difference between tool calling and an AI agent?

Tool calling is the mechanism: the model requests actions through tools. An agent is a system that uses tool calling in a loop to complete multi-step goals with some autonomy. Every agent needs the gateway and tier controls described here; not every tool-calling assistant needs to be an agent.

Can the AI connect to Paystack or Flutterwave to check payments?

Yes, through your gateway, using the provider's official API to verify a transaction reference. The tool should return the provider's real status and never accept screenshots as proof. Check the provider's developer documentation for verification endpoints and rate limits.

Is MCP (Model Context Protocol) something we need?

It is a standard way of exposing tools to AI clients, useful when several assistants or tools must share the same connections. It does not replace authorisation, validation or logging; you still need the gateway behind it.

How do we stop the AI from doing something harmful?

Tier the tools, require confirmations for Write and Spend, cap amounts, validate every input in code, log everything and review the logs. The model should be physically unable to do what the gateway does not allow, regardless of how it is prompted.

Will this work with our custom-built software?

Yes, if it exposes an API or can have one added. Custom systems are often the easiest to connect because you control the interface and can design endpoints specifically for the tools you need.

How many tools should we start with?

Three to five Read tools covering the most frequent questions. Expand only when logs show the existing tools are chosen correctly and the answers are accurate.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Paystack developer documentation
• Flutterwave developer documentation
• PostgreSQL documentation
• OpenAI platform documentation
• Anthropic developer documentation