Software Development
APIs & Systems Integration
Connecting agency systems so data moves without re-keying.
What this covers
Agencies run dozens of systems from different vendors. Integration makes them work together: permits update the GIS, dispatch feeds records, payments post to finance. HQT designs and builds integrations and the APIs that make them maintainable.
Typical activities
- Integration inventory and mapping of data flows
- API design and implementation, including public APIs for open data
- Integration platform selection or configuration
- Event-driven and batch integration patterns as appropriate
- Error handling, monitoring, and reconciliation
- Vendor coordination for systems with limited interfaces
What you receive
Documented integrations, API specifications, monitoring, and runbooks for common failure modes.
Why it matters
Manual re-keying between systems is where errors and delays enter. Good integration removes it and gives the agency a single source of truth for each kind of record.
Where the need usually shows up
Integration work tends to get funded after a visible failure rather than before one. The conditions below can be checked without an assessment:
- A spreadsheet exists whose only purpose is to reconcile two systems that are supposed to agree.
- The same record is keyed into a second system by a second department, with no automated check that the copies match.
- A nightly file transfer runs, but nobody is alerted when it does not, and failures surface as a resident complaint or a month-end variance.
- A vendor has quoted a separate charge to enable an interface the base contract implied was included.
- Answering a records request means pulling the same subject from several systems, one of which exports only to PDF.
- A replacement system is in procurement and the requirements say nothing about how it will exchange data with the systems the agency already runs.
Where several of these hold, the interfaces rather than the applications are the more likely source of the problem.
Design decisions that determine whether an interface lasts
Every interface needs a written definition covering fields, types, required values, and the behavior when a value is missing or malformed. A few decisions beyond that definition tend to separate interfaces that survive vendor upgrades from those that do not:
- Version the definition and name an owner inside the agency, not only at the vendor.
- Make transfers idempotent, so re-running a batch does not create duplicate records.
- Record a count in and a count out for each run, so agreement between systems can be demonstrated rather than asserted.
- Provide a documented way to replay a failed run without editing a database directly.
- Map to a recognized exchange standard where one applies. NIEM offers a common vocabulary for exchanging information across justice, public safety, and other government domains, and NENA i3 specifications describe interfaces in an NG911 environment. Confirm which version or profile applies to the program before design.
Two patterns are worth rejecting early: an integration that reads or writes another vendor's database tables directly, which tends to break at their next upgrade and may put support at risk, and mapping logic that exists only inside a hosted tool the agency cannot export.
Interface terms to settle before award
Interface obligations are easier to obtain before award than after:
- State that the agency owns its data and may extract all of it in bulk, in a documented non-proprietary format, during the term and at termination, without an additional charge.
- Require programmatic access to the agency's own data within the base subscription, and require any per-interface or per-transaction fee to appear in the price schedule rather than in a later quote.
- Name each integration in the statement of work with its direction, its trigger, and a field-level mapping as a deliverable.
- Make an interface specification, test data, and a non-production sandbox contractual deliverables, with sandbox access available to a third party the agency designates.
- Tie acceptance to a reconciliation test on agency data rather than a demonstration on vendor data.
- Carry data-specific obligations through to the interface, its queues, and its logs: the FBI CJIS Security Policy for criminal justice information, IRS Publication 1075 for federal tax information, and HIPAA where the agency or program acts as a covered entity or business associate.
Measuring the result
Record the baseline before the build starts, since the cost of the old process is hard to reconstruct afterward.
- Manual touches removed. The re-keying steps in the process, counted before and after.
- Latency. Time between an event in the source system and its appearance downstream, against a target agreed during design.
- Time to detect a failed run. If the answer is that someone eventually notices, the alerting is not finished.
- Exception volume and ownership. An interface that routes a large share of records to an exception queue has moved the manual work rather than removed it, and that queue needs a named owner.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
How is a systems integration project usually priced?
Cost is driven mainly by the number of interfaces, whether each one is one way or bidirectional, and how much cooperation each system's vendor provides, rather than by the volume of records moved. A scheduled one way export from a system with a documented API is a small piece of work, while a two way sync between two closed products with no test environments is not. Ask for pricing per interface rather than one lump sum, so the work can be staged or paused. Budget separately for ongoing monitoring and for the rework that vendor upgrades will eventually require.
What can we do if our software vendor charges extra for API access or will not open an interface?
Access to your own data is a contract question before it is a technical one, so start by reading the current agreement for its data ownership, export, and interface language. The practical leverage points are renewal, any pending change order, and the next procurement, where bulk export and programmatic access can be required inside the base price. In the meantime there are usually supported alternatives, including scheduled file exports, vendor reporting extracts, and a read only database replica provided by the vendor. Avoid unsupported workarounds such as reading the vendor's production tables directly, which can breach the agreement and break at the next upgrade.
Should we buy an integration platform or build point to point connections?
A platform is worth its license and learning curve when an agency has many interfaces, more than one team building them, and a real need for shared logging, retries, scheduling, and credential management. For a small number of connections it can add a license, a new skill requirement, and a dependency without reducing the actual effort. Whichever route you take, record the decision and the exit path, since mapping and transformation logic should be exportable and readable outside the tool that runs it.
How do we integrate a legacy system that only supports flat file exports or nightly batch?
Batch is a legitimate integration pattern rather than a failure, and many mainframe and older client server systems support nothing else. The work is making it reliable: a defined schedule, a record count or checksum verified on both ends, an alert when an expected file does not arrive, a documented replay procedure, and a reconciliation report. Reserve event driven interfaces for the flows where timeliness genuinely changes an operational outcome, and leave the rest on a schedule that matches how the data is actually used.
Does an integration between agency systems have to meet CJIS or other security requirements?
Usually yes, and the obligation follows the data rather than the system it came from. Criminal justice information remains subject to the FBI CJIS Security Policy as it moves through an interface or sits in a staging area, federal tax information carries IRS Publication 1075 obligations, and health information may fall under HIPAA depending on the program. Treat message queues, logs, and error files as in scope, because they frequently contain complete record content. Confirm the current version of each policy and any state specific requirements with your state CJIS systems agency or the relevant program office before design.