SQL Server Integration & APIs

Somewhere in most businesses there’s a person typing the same figures into two systems. Orders from the database into the accounts package, delivery details from an email into a spreadsheet, stock counts from a clipboard into a form.

It’s slow, and worse than slow it’s where the errors come from — the two systems disagree and nobody knows which one is right.

We connect SQL Server to whatever else you run, so the number gets entered once. ☎

Email, Microsoft 365 and Exchange

[IMG-1] — Right-aligned. Database Mail configuration or a send log, redacted. The reader here is technical and looking for evidence you’ve done this before.
Alt: SQL Server Database Mail configuration for Microsoft 365

If your SQL Server has stopped sending email, this is almost certainly why.

Microsoft has retired basic authentication for SMTP client submission in Exchange Online. SQL Server’s Database Mail has no native OAuth 2.0 support, so setups that worked for years — overnight reports, order confirmations, alerts, failure notifications — stop dead, usually without anyone noticing until somebody asks where their report went.

Sending

• SMTP direct, or via a relay or connector authenticated by certificate or IP rather than a username and password
• Microsoft 365 and Exchange — Exchange Online, on-premises Exchange, and hybrid
• Mailgun and similar providers where volume, deliverability or tracking matter. Bounces, opens and delivery failures come back as webhooks and get logged against the record, so you can see the invoice actually arrived.
• Azure Communication Services, where the estate is already in Azure
• Microsoft’s High Volume Email, where the traffic is internal and the volume justifies it

Making sure it arrives

Email sent by a system gets filtered harder than email sent by a person, and the rules tightened again when the large mailbox providers started enforcing authentication on bulk senders. SPF, DKIM and DMARC need to be right, and in most businesses we look at they aren’t — often because nobody realised the database was sending mail at all.

Receiving

The half most people never set up: mail read into the system rather than sent from it — POP3, IMAP, or Microsoft Graph for Microsoft 365.

• Orders and enquiries arriving by email, logged against the customer automatically instead of being forwarded round the office
• Supplier confirmations, PODs and remittances filed against the job
• Replies threaded onto the original record, so the history sits in one place
• Bounces and out-of-offices handled rather than ignored
• Attachments extracted and stored against the record

Beyond fixing it, the useful version: quotes, order confirmations, statements, job sheets, service reminders and chase letters generated from live data, sent automatically, and logged so anyone can see what went out and when. Calendar and contact sync where it earns its keep.

Accounts and finance

Orders or invoices raised in the database, posted into the accounts package without rekeying, with customer, supplier and nominal data kept in step both ways.

Sage 50 and Sage 200, Xero and QuickBooks. Older Sage and Mamut installations still turn up and we can still work with them.

What matters more than the connection is what happens when something doesn’t match — a customer in one system and not the other, a code that’s changed, a posting that fails. We build that in from the start, with a log you can read and a way to fix the exception. That’s what decides whether people still trust the integration in six months.

Files and documents

Drawings, certificates, photographs, signed paperwork and correspondence held against the record they belong to.

Stored properly — outside the database rather than bloating it — with controlled access, version history and an audit trail of who added and who opened what. For anything holding personal data, that audit trail is the part your auditors ask about.

Barcode and scanning

Stock, goods in, picking, dispatch, asset tracking and plant hire.

Handheld and fixed scanners, label design and printing, and the hardware advice to go with it — we’ve delivered integrated barcode solutions across logistics, retail and rental, and the hardware choice matters as much as the software.

Where staff are out of the building, the scanning usually wants to be on a phone rather than a dedicated device → mobile apps for existing systems

SMS and messaging

Delivery notifications, appointment reminders, engineer-on-the-way texts, and two-way messaging where customers reply.

SMS and MMS through the main UK gateways, and WhatsApp through the Business API where that’s where your customers already are. Replies come back into the system and sit against the record, rather than on somebody’s phone.

Website, CMS and customer-facing systems

The data in your database is usually the same data your customers are ringing up to ask about. Joining the two together removes a lot of phone calls.

• Website and CMS — WordPress and other content systems kept in step with the database: products, pricing, stock, availability, branches, staff, documents
• Web forms straight into the system — enquiries, bookings and requests landing as records rather than as emails somebody retypes
• E-commerce — orders in, stock and pricing out, customer accounts consistent in both places
• Customer portals — order status, documents, previous jobs, invoices → customer portals and self-service
• Surveys and feedback — SurveyMonkey and similar, triggered by something happening in the database. Job completed, survey sent, response logged against that job and that engineer. Feedback stops being a quarterly spreadsheet and starts being something you can report on.

APIs and application integration

The broader job, and most of what we’re asked for now.

• REST APIs over SQL Server, so web and mobile applications talk to a proper interface rather than straight to the tables
• Consuming other people’s APIs — couriers, payment providers, e-commerce platforms, EPOS, CRM, suppliers and customer portals
• Webhooks, so something happens the moment it happens rather than on the next overnight run
• SSIS packages for scheduled bulk movement, built to be maintainable rather than a black box
• Linked servers and pass-through queries where two SQL estates need to talk
• Change tracking and CDC, so downstream systems get what changed rather than a full copy every night
• Queues and background processing, so a slow third-party API doesn’t lock up somebody’s screen
• File-based exchange — CSV, XML, fixed-width drops — because plenty of business software still offers nothing else, and it works perfectly well

How we build integrations that stay built

An integration that needs babysitting every Monday isn’t finished.

• Credentials in Key Vault or a managed identity, never in a config file or a stored procedure
• Retries and back-off, so a third party being down for ten minutes isn’t an incident
• Failures that alert somebody, rather than failing silently until month end
• A log a non-technical person can read, and a way to reprocess what failed
• Documented, so you’re not dependent on one person understanding it

SQL Server support and consultancy

BLOCK 12 — CTA

    


                    
What's being typed in twice?
        
                    
Tell us which two systems aren't talking and what moves between them. We'll tell you whether it can be joined up, how, and what it costs to keep running.
        
                    
                Send us the details →
            
        
                    
                How we work →