Information Technology
Didloo Business API: Templates, Onboarding and Customer Replies
The Didloo Business Messaging API connects business software to approved messaging on the Didloo network. It is separate from personal chat and from WhatsApp transport. A useful integration plan must account for business identities, phone verification, template approval, the intended category and the evidence available after a send. This independent guide uses a fictional bookshop to explain those decisions. It does not issue an API request, change an account, submit a template or claim a measured delivery result.
Start by identifying where the customer receives messages
A business messaging decision begins with the destination network. Didloo's public overview describes reaching Didloo users through its own independent platform. A customer's presence on a different messaging service does not establish that they can receive a Didloo conversation there.
Harbour Books is a fictional shop planning customer order updates. Before choosing an integration, it should determine whether the intended customers use Didloo and understand that this is the selected destination. This is more useful than comparing product names alone. A technically valid request cannot bridge an unadvertised network connection. Keep customer expectations clear, and evaluate the real receiving experience rather than assuming that a familiar business-messaging concept makes all platforms interchangeable. The shop's communication plan and its chosen transport need to describe the same audience.
Use WhatsApp as a conceptual reference accurately
The WhatsApp Business API is a recognisable reference for connecting business software to a messaging platform. Didloo's public page explicitly states that its Business API is not a WhatsApp API provider, does not use WhatsApp transport and has no affiliation with WhatsApp or Meta.
For Harbour Books, that distinction belongs in the evaluation brief. A project described internally as WhatsApp order notifications would be misleading if the selected integration actually sends Didloo messages. Correct the destination before discussing templates or credentials. This article does not rank the platforms or claim a drop-in replacement. It explains the Didloo workflow on its own terms so that the shop can decide whether it matches its customers, its operational process and the network through which it intends to communicate.
Separate the business account from a personal conversation
Didloo provides a business dashboard for managing the messaging workflow, while the consumer app and linked personal Web experience serve personal conversations. The standing product rules distinguish the email-authenticated business customer from a physical messaging phone identity. Those roles should not be collapsed into a single vague account label.
In the fictional shop, the person responsible for administration and the phone identity presented to customers have related but different purposes. Record which account owns the configuration and which business phone will send. A personal chat session is not a substitute for the business approval path. This is an explanation of the product boundary, not permission to inspect another account's records or reuse consumer credentials to bypass a business restriction that the current dashboard requires.
Establish the business before planning a live send
The public onboarding sequence begins with creating the business account and setting up the business. Read the actual dashboard requirements and prepare the necessary information through that authorised workflow. An outline in a blog is not a substitute for completing the application's current review process.
Harbour Books can first assign responsibility for the business details and confirm who will maintain them. Keep the decision separate from writing a sample notification. A convincing message draft does not mean the sender has been approved. This planning order helps the shop recognise which work is editorial and which work establishes permission to use the platform. The example is fictional; no application, document upload or approval request is carried out by this guide, and no approval outcome is promised.
Treat the sending phone as a controlled identity
Didloo's public Business API page includes adding a business phone and completing verification and approvals. The standing product rules also require current ownership and approval conditions for outgoing messaging. Follow the actual account flow rather than treating a telephone number typed into a form as a ready sender.
The shop should identify the intended sending phone before designing customer-facing wording around it. A change in ownership or assignment is not merely a cosmetic update to a label. Keep the current dashboard state authoritative and investigate any incomplete prerequisite before attempting a send. This is a practical integration boundary: the application must use the authorised business identity for the intended action, not whichever account or number happens to make a demonstration appear successful.
Review personal-to-business number requirements carefully
Didloo's public overview says that a personal app number must be intentionally deleted before it can be verified for Business use, and vice versa. It also states that account histories are not merged when changing account types. Do not reinterpret those conditions as an automatic conversion that preserves all earlier conversations.
For Harbour Books, selecting a business phone should therefore be a deliberate planning decision. This article does not instruct anyone to delete an existing personal identity or perform a migration. Review the current account requirements and the consequences for the specific identity before taking a lifecycle action. A reusable guide should make the distinction clear without inventing a recovery promise or suggesting that a different login can erase the product's separation between personal and business registration.
Match the message to the approved category
The Business API initiates approved OTP, transactional and promotional template messages. These categories have separate purposes and approval requirements. Choose the intended route from the actual use case and the current template workflow; do not select a category merely because it appears easier to submit.
Harbour Books might need an order-status update, while an announcement about a forthcoming sale serves a different purpose. Keep those drafts and their approvals distinct. The category is part of the authorisation context, not a decorative label that can be changed after content review. This article does not provide a loophole for sending unrestricted text through a route intended for approved templates. The shop should describe what it wants to communicate honestly and follow the requirements for that message.
Understand the scope of an OTP template
Didloo's public page describes OTP templates for approved verification-message use cases. An approved OTP message is one part of the business's wider verification design. It does not automatically determine which action a successful code entry authorises in the business's own application.
For a fictional customer account, Harbour Books should distinguish proving access to a contact channel from granting access to every historical order. The pending action, account context and result handling belong in the shop's design. This is an application-planning recommendation, not a claim that the Didloo messaging endpoint implements the shop's entire authentication system. Keep the approved message purpose narrow, and use the current documented workflow rather than assuming that any text containing a number becomes an equivalent verification service.
Keep transactional updates connected to a real event
The transactional category is described for approved customer updates. A useful message should correspond to the business event it claims to describe. The template and its permitted variables need to support that intended meaning without using the category as a general-purpose advertising channel.
Harbour Books could plan an update when a particular order is ready for collection. Its own order system must first establish that fact. Receiving an accepted messaging response should not mark the order as ready if the fulfilment process has not done so. Keep the business event and notification attempt as separate records. That distinction gives staff a useful investigation path when the customer asks about an update: what happened to the order, and what happened to the message about it?
Keep promotional templates distinct from service replies
Didloo's public information presents promotional templates separately, subject to the required approvals, phone proof and credit checks. The Business API's category restrictions still apply when planning a campaign. A customer-service conversation does not make an arbitrary promotional API body an approved template.
For the fictional shop, an announcement about a reading event should have an honestly described purpose and appropriate audience. Do not treat a previous order conversation as a universal explanation for sending any future content. This is a planning principle rather than a statement of legal advice or a promise about campaign performance. The shop needs to choose the correct approved workflow and review the actual requirements before sending, while keeping its own customer communication expectations clear.
Prepare the complete template before submission
A template review should have a concrete message to assess. Settle the fixed wording, intended category and variable meaning before treating a draft as ready for submission. Use the current dashboard's actual requirements and examples, rather than copying a different platform's fields into the process.
Harbour Books can create a small editorial record for each proposed template: why it exists, which business event uses it and what each value will represent. Keep that record separate from an approval result. A local draft is not submitted; a submitted template is not approved; and an approved template still operates within its category and sending prerequisites. These distinctions make project status useful to the staff who need to know what is genuinely ready instead of relying on an ambiguous complete label.
Use variables to fill the approved meaning
The standing Didloo template rules support named placeholders, with the approved fixed text preserved and values constrained by the documented contract. Read the current authenticated reference for the exact names, value limits and reserved variables. Do not infer a send payload from a visual example or treat a variable as a way to replace the entire approved message.
In an order-ready template, the shop could plan which order reference belongs in the appropriate value. Check that the value is meaningful to the recipient and does not reveal unrelated account information. This is an editorial and application responsibility. A placeholder name does not confer permission to access another customer's order, and filling an approved slot does not authorise a different category or an unreviewed change to the surrounding message.
Keep template edits separate from earlier approval
A template that was approved in one form should not be represented as authorising arbitrary later wording. Didloo's standing rules distinguish reviewed versions and require normal review when edited. Use the actual dashboard state for the version the integration intends to send.
Harbour Books might change an instruction about collection times. Treat that as a content decision with its own review implications, not a harmless substitution hidden inside a deployment. Record which version the shop's software expects. This makes it easier to diagnose an attempted send that no longer matches the current approval. The article does not promise immediate approval or a review duration; it explains why the approval state must refer to the actual content and business context being used.
Keep API keys on the server
The public Business API overview identifies API keys as private credentials and directs businesses to keep them server-side. Manage keys in the authorised dashboard and follow the current documentation for authentication. A publicly visible example should never contain a real key.
For a prospective shop integration, distinguish the component creating a send request from the staff page displaying its result. Those components do not automatically need identical authority. Document where the secret is loaded, who is responsible for it and how it can be replaced without including the value in the record. This guide does not create or rotate a key. It explains why a convenient browser form should not receive a credential capable of initiating unrelated business messages merely to display a customer's order status.
Read the current endpoint contract before implementation
Didloo links its API documentation and message, template, scheduling and delivery-report destinations from the public overview. Use the current authenticated reference for actual requests and responses. A blog's conceptual example is not a replacement for the exact contract, ownership checks and errors the integration must handle.
Harbour Books can first map its intended business action to a documented operation. Then identify the required inputs and the expected evidence of acceptance or failure. Do not guess field names from another provider or rely on an old screenshot to build a production request. This planning stage should result in a concrete understanding of the selected endpoint, while keeping private documentation access and account credentials within the authorised team's existing boundaries.
Recheck prerequisites when a message is actually sent
The current Didloo rules require more than a key that once worked. Sending depends on the relevant business and phone state, current approvals, phone proof, permitted template category and sufficient credits. Use the live requirements shown by the account and documented workflow.
For Harbour Books, a successful controlled test last week does not establish that today's phone verification or template state is unchanged. The application should interpret a rejected operation accurately instead of silently switching to a different sending route. This is a product-boundary explanation, not a new endpoint specification. Keep the business event safe while investigating the notification failure. An order should not be cancelled or duplicated merely because the corresponding communication attempt could not proceed under its current prerequisites.
Evaluate costs against the actual planned workflow
Didloo's public overview says that outgoing messaging is subject to current credit rates and checks shown in the dashboard. Read those current figures when preparing a real estimate. This article provides no live rate or claim that one category is always the cheapest.
The fictional shop can estimate order updates, verification messages and promotional sends separately. Mark the assumed volume and time period clearly, and account for the operational work of reviewing exceptions. A price remembered from an earlier project is not a reliable basis for every future category or account state. No credit calculation, purchase or paid message is performed here. The goal is a transparent evaluation that relates the business's actual task to the current authorised workflow instead of an unsupported headline-cost comparison.
Schedule a message only while its purpose remains valid
Didloo's public API overview includes scheduling and management of scheduled sends through documented endpoints. Read the exact current lifecycle before integrating. A planned message has both a technical schedule and a business reason; the latter can change before the sending time arrives.
Harbour Books might plan a reminder for an upcoming collection. If the collection arrangement changes, the application needs an explicit decision about the scheduled notice rather than leaving stale instructions in a queue. Keep the intended event and the schedule reference connected. This is an original application recommendation, not a claim that the messaging platform automatically reads the shop's order system and cancels notifications when business records change. The team remains responsible for keeping the communication relevant to the current arrangement.
Record the public message identity accurately
Didloo's standing API documentation rules identify the public message reference with message_id and delivery_type for immediate or scheduled delivery. Use the current reference for the exact response and subsequent operations, and keep private transport or worker identifiers out of customer-facing descriptions.
For the shop, an internal order reference and the message reference answer different questions. The first locates the sale or collection; the second helps investigate its communication. Store their relationship explicitly instead of expecting the message body to be the only connection. This recommendation makes reports easier to interpret when wording changes or several legitimate updates concern the same order. It does not suggest that the two identities are interchangeable or that knowing a reference grants access to another customer's records.
Interpret delivery reports without inventing customer agreement
The public overview includes message delivery reports. Read the current documentation to understand the actual fields and states returned. Do not assign unverified meanings to a status or treat every successful technical stage as proof that a customer understood the content.
Harbour Books should define the operational question behind a report. Staff may need to know whether an attempt was accepted, what outcome information is available and which action needs attention. A customer's agreement about a changed collection time is a separate communication matter. This guide intentionally does not invent a complete status enumeration or universal read-receipt guarantee. Use the documented evidence and ask for an ordinary confirmation when the real arrangement requires one, rather than claiming more than the platform reports.
Investigate an uncertain attempt before retrying
A missing or delayed response is an incomplete observation. Before the shop submits a new request, inspect the recorded attempt and the documented result-retrieval path. Do not assume that identical message text creates an automatic duplicate-prevention boundary.
Harbour Books can keep a local intention record for the order update and connect each actual attempt to it. If an operation's outcome is uncertain, staff should be able to distinguish investigation from authorising a new message. This is an application design recommendation; the article does not invent a public idempotency parameter or promise that repeated send requests are collapsed. Follow the current API's error and identity rules while protecting the customer's experience from unnecessary repetition and keeping the original business event distinct from every notification attempt.
Use Business Web for its approved customer-service role
Didloo explicitly distinguishes Business Web replies from Business API initiation. The API sends approved OTP, transactional and promotional templates. Business Web supports service replies from approved business phone identities within the configured customer-initiated reply window. Login does not reopen that window.
For Harbour Books, a customer asking a question can lead to an authorised service conversation through the appropriate Business Web workflow. That does not expose a free-form service-send exception through the API. Keep the current reply window and other prerequisites authoritative, rather than treating an open employee screen as permission to initiate any message. This boundary is essential to planning the correct interface for support staff and the correct API operation for automated updates.
Test English and Hindi message meaning deliberately
An English and Hindi customer workflow should preserve the same business event, requested action and limitations. Review the fixed template wording and the values that will fill it. Similar character counts or visually balanced layouts do not establish equivalent meaning.
The shop can compare a fictional order-ready update in both languages against one approved event brief. Check the collection reference, the timing and any instruction whose meaning changes when a negative is omitted. Keep the test material fictional and mark it as an editorial exercise, not a submitted template or native-speaker certification. Language review and platform approval are separate stages. Neither should be represented as proof of the other, and a translated local draft must not be described as available for sending until the actual required workflow is complete.
Release a narrow workflow with evidence
A useful release record identifies the intended recipients, approved sender, template version, current prerequisites, selected endpoint and observed test outcomes. Include a clear failure case and the staff action it should produce. Keep the record factual about what was actually tested instead of claiming that every business use case is ready. Use a synthetic example for the planning record: one fictional order, one intended recipient and one agreed template version. State the expected outcome before testing, then record the observation without replacing the expectation after the fact.
Harbour Books' first successful project might be one well-defined order-update workflow for customers using Didloo. Future promotional or service processes need their own evaluation of the relevant rules. The platform supplies a controlled business messaging workflow; the shop remains responsible for its business facts, application permissions and customer communication decisions. That separation supports a reviewable integration without invented WhatsApp compatibility, guaranteed approvals or unsupported claims that accepting an API request automatically completes the underlying business task.
Further reading
Official resources and related guides for the concepts discussed above. Check the selected tool for current capabilities and terms.
- Didloo: official Business Messaging API overview
- Didloo: independent network and WhatsApp comparison
- Didloo: template submission reference (account sign-in required)
- Didloo: immediate message reference (account sign-in required)
- Didloo: scheduling reference (account sign-in required)
- Didloo: delivery report reference (account sign-in required)
Take the next idea into a conversation
Explore Didloo for personal chats, creative sharing and linked desktop messaging. Business messaging has its own approved API workflow.
