Understanding ACORD Forms API Integration for Insurance Brokers

ACORD forms API integration sends structured insurance data directly from your agency management system to a carrier's underwriting platform without generating a PDF. A submission that takes 15-25 minutes as a PDF drops to under 2 minutes through an API connection. As of the ACORD 2025 Technology Report, 22% of U.S. carriers accept API-based ACORD submissions, and that number is projected to reach 35% by year-end 2026. For high-volume agencies processing 100 or more submissions weekly, ACORD forms API integration is the highest-ROI technology investment available.

This tutorial explains what ACORD forms API integration involves, which carriers support it, and how to implement it step by step.

Key Takeaways

• ACORD forms API integration eliminates PDF generation and carrier portal logins by exchanging structured data (ACORD XML or JSON) directly between your AMS and the carrier's underwriting system
• Processing time per submission drops from 15-25 minutes via PDF to under 2 minutes via API, according to ACORD 2025 Technology Report benchmarks
• 22% of carriers accept API submissions in 2026, with Travelers, Hartford, Liberty Mutual, and Nationwide leading adoption; this figure is projected to reach 35% by year-end
• Applied Epic and Vertafore AMS360 both support outbound API calls natively; agencies on other AMS platforms can use middleware platforms to bridge the gap
• Field mapping between your AMS data model and the carrier's ACORD schema is the most time-intensive step; expect 10-20 hours of mapping work per carrier integration
• IIABA's 2024 Agency Universe Study found that API-integrated agencies report error rates below 1%, compared to 8-12% for email PDF workflows, because API schemas enforce data validation before submission reaches the carrier

How API Integration Differs from Other Submission Methods

The traditional ACORD workflow has four steps: fill a PDF, email it to an underwriter, wait for the carrier to re-enter the data into their system, and wait for a response. API integration reduces this to one step: the AMS sends structured data and the carrier's system processes it automatically.

The table below shows how submission methods compare across the five dimensions that most affect agency operations.

When you submit via API, the carrier's underwriting system receives pre-validated, structured data that loads directly into the correct fields. No underwriter re-enters anything. No OCR misreads a field value. The submission data is exactly what your AMS sent.

The carrier-side time saving matters as much as the agency-side saving. Carrier manual data entry has historically accounted for 2-4 business days of the total submission-to-quote timeline. API submission eliminates that delay entirely for carriers with automated underwriting rules for standard risks.

The ACORD Data Standards Behind API Integration

ACORD (Association for Cooperative Operations Research and Development) publishes data standards that define how insurance information moves between systems. Two formats handle the majority of API integrations today.

ACORD XML. The established standard used in agency-carrier integrations since the mid-2000s. ACORD maintains XML schemas for every major line of business. The commercial lines schema (ACORD XML P&C) covers applications, quotes, binders, policies, endorsements, and certificates. XML is verbose but well-supported across carrier platforms. If a carrier built their API before 2022, it almost certainly uses XML.

ACORD JSON. The newer standard gaining adoption since ACORD published its JSON schemas in 2022. JSON is lighter, easier to implement for modern web-based systems, and the default format for InsurTech carriers and those building new platforms. ACORD expanded its JSON schema coverage to include commercial applications, binders, and endorsements in the 2024 standard release. The ACORD 2025 Technology Report reports that JSON adoption in new carrier API projects reached 61% in 2025, even as XML remains dominant in existing integrations.

Your AMS and the carrier must agree on which format to use. Most live integrations in 2026 run XML. Most new integrations under development use JSON. Your tools need to handle both.

Which Carriers Support API Submissions

Carrier API adoption falls into three distinct tiers. Before committing to API integration investment, map your top 10 carriers by premium volume into these categories.

Tier 1: Full API support. Carriers with documented public APIs, developer portals, sandbox testing environments, and dedicated integration support teams. These carriers accept new business applications, return quotes, and issue binders through the API without human intervention for standard risks. As of 2026, this group includes Travelers, Hartford, Liberty Mutual, Nationwide, Berkley One, Coterie Insurance, and Next Insurance. InsurTech carriers in this tier are typically JSON-only. National carriers generally support both XML and JSON.

Tier 2: Partial API support. Carriers that accept certain form types via API (most commonly certificates of insurance and policy change requests) but still require PDFs or portal uploads for new business applications. Many super-regional and regional carriers fall in this tier. Some use API for commercial lines but not personal lines. Tier 2 carriers are worth integrating for certificate automation even if full application submission is not yet available.

Tier 3: Portal only. Carriers that offer a web portal for submissions but have no programmatic API. Your options here are portal upload (which requires a human to log in) or screen-scraping automation (fragile, violates most carrier terms of service, and not recommended). Tier 3 carriers will not benefit from API investment. Focus electronic submission efforts on portal uploads for this group.

If your top three carriers by premium volume are in Tier 1, API integration delivers immediate ROI. If the majority of your premium sits with Tier 3 carriers, focus on portal-based submission and revisit API options annually as carrier adoption expands.

Technical Requirements for Implementation

API integration is not a single product you buy. It is a connection between two systems, each with its own data model, validation rules, and communication protocols. Here is what the implementation requires on the agency side.

AMS with API capability. Your agency management system must support outbound API calls, meaning it can package data from your client and policy records and send it to an external endpoint in real time. Applied Epic supports outbound API connections through its API framework, with pre-built integrations for several Tier 1 carriers. Vertafore AMS360 supports outbound API through its BriteLines integration layer and direct carrier connections. HawkSoft offers API access through its HawkLink framework, primarily for quoting integrations. If your AMS does not support outbound API, a middleware platform sits between your AMS and the carrier, receiving data via export or screen read and reformatting it as an API call.

Carrier API credentials. Each carrier issues API keys, client IDs, and client secrets specific to your agency. You register as an API consumer through the carrier's developer portal, providing agency credentials, appointment documentation, and technical contact information. Carrier approval takes 2-6 weeks depending on the carrier's onboarding process. Some carriers, particularly those on IVANS, require your AMS vendor or a certified technology partner to act as the API intermediary rather than connecting directly.

Field mapping between data models. Your AMS stores data using its own schema and field naming. The carrier's API expects data in ACORD-standard field names and formats. Field mapping is the translation layer. It defines which AMS field maps to which ACORD element and how the data format should transform. For example, your AMS might store business type as a text description. The carrier's API expects the ACORD-standard SIC or NAICS code. The mapping layer handles that translation automatically.

Field mapping is typically the most labor-intensive step. A thorough mapping for a commercial lines carrier covers 80-150 fields. Expect 10-20 hours of initial mapping work per carrier, plus testing. Each subsequent carrier integration goes faster because much of the base mapping reuses the work done for the first carrier.

Error handling and retry logic. When an API call fails (carrier system down, validation error, network timeout, expired credentials), your system needs a defined response. Options include automatic retry after a set interval, queuing the submission for manual review, or alerting the responsible CSR. Every failure must be logged with enough detail to diagnose the cause. Without reliable error handling, failed API submissions disappear silently and create coverage gaps.

SSL/TLS encryption. All API submissions travel over encrypted connections using HTTPS with TLS 1.2 or higher. This is standard for any modern web integration and a firm requirement for any carrier handling protected client data.

Audit logging. Every API call must generate a log entry capturing the timestamp, the submission contents, the carrier's response, and the final status. This log serves as the agency's documentation that submission occurred and when. State insurance departments and E&O carriers increasingly treat API submission logs as the authoritative record for compliance audits.

How Applied Epic Handles ACORD API Submission

Applied Epic is the most widely used AMS at agencies above $5 million in premium. Its API integration capabilities are worth understanding in detail because the framework shapes how the majority of commercial agency API integrations work.

Applied Epic maintains direct carrier connections for a subset of Tier 1 and Tier 2 carriers through its IVANS Exchange and direct integration program. For these carriers, submitting via API within Applied Epic involves selecting the carrier, reviewing the pre-populated ACORD form, and clicking submit. The AMS handles the API call, field mapping, and response processing.

For carriers not in Applied's pre-built library, agencies use the Applied API framework to build custom connections. This requires a technology partner or internal developer with API integration experience. Applied publishes its API documentation through the Applied Technology Exchange (ATX) developer portal.

The practical limitation of Applied Epic's API framework is the same as all AMS-native solutions: the carrier must either be in the pre-built library or your agency must invest in custom integration development. Most agencies with Applied Epic use the pre-built carrier connections for their Tier 1 carriers and fall back to portal upload for the rest.

How Vertafore AMS360 Handles ACORD API Submission

Vertafore AMS360 approaches carrier connectivity primarily through its BriteLines integration layer and direct connections maintained by Vertafore's carrier relations team. AMS360 agencies access ACORD XML-based submission for supported carriers through the BriteLines interface, which handles field mapping and format conversion automatically.

Vertafore also maintains an API marketplace through its Vertafore Open Platform (VOP). Partners and carriers that join VOP publish integration endpoints that AMS360 users can activate. This has expanded the number of Tier 1 carriers accessible through API submission for AMS360 agencies considerably since 2023.

For agencies on AMS360, the practical path to API integration typically involves: checking the Vertafore Open Platform for your top carriers, activating available connections, and working with Vertafore's carrier relations team to request support for carriers not yet on the platform.

Data Mapping Requirements in Detail

Field mapping is where API integrations succeed or fail. A common misconception is that all ACORD data is the same. It is not. ACORD publishes standard schemas, but carriers implement them with variation.

Required vs. optional fields. The ACORD XML schema marks some fields as required and others as optional. Individual carriers make their own choices about which ACORD optional fields they require for their underwriting process. A field that is optional in the ACORD schema may be required by Carrier A but not Carrier B. Your field mapping must capture these carrier-specific rules.

Enumerated values. Many ACORD fields accept only specific coded values. Business type fields use SIC codes (4-digit) or NAICS codes (6-digit). Coverage form types use specific ACORD-defined codes. Your mapping must translate plain-language AMS values into the correct ACORD enumerated values for each carrier.

Conditional fields. Some ACORD fields appear only when other conditions are met. Workers compensation submissions require payroll by classification code. Claims-made forms require retroactive date and prior acts coverage fields. Occurrence forms require per-occurrence and aggregate limit fields in specific schema positions. The mapping must handle these conditionals cleanly, populating the right fields based on coverage type and form selection.

Address standardization. ACORD requires addresses in USPS standard format. If your AMS stores addresses with non-standard abbreviations, the mapping layer must standardize them before submission. Carriers with real-time validation will reject non-standard addresses immediately.

Currency formatting. Premium amounts, coverage limits, and deductibles follow ACORD-specified decimal formats. An AMS that stores coverage limits as "$1,000,000" must map to a field expecting "1000000" (no commas, no dollar sign) in the API payload.

Error Handling When API Submissions Fail

Every API integration generates errors. The question is whether your workflow handles them or ignores them.

Validation errors. The carrier's API rejects the submission because a required field is missing, a value is outside an acceptable range, or a format is wrong. The API returns an error code and message specifying which field failed. Your form tool should surface this error to the CSR with a plain-language explanation. The CSR corrects the field and resubmits. These errors should resolve in under 5 minutes for a well-mapped integration.

Authentication errors. The carrier's API rejects the submission because API credentials have expired, changed, or been revoked. These errors require contacting the carrier's API support team to renew credentials. Credential expiration is common (most carrier API keys expire every 12-24 months) and is almost always overlooked until a submission fails. Set calendar reminders 30 days before each carrier API credential expiration.

Carrier system errors (5xx responses). The carrier's API returns a server error, meaning the submission reached the carrier but failed to process due to a carrier-side system issue. These are not agency errors. Your system should queue the submission and retry automatically after 15-30 minutes. If three retry attempts fail, alert the CSR to submit via portal as a fallback.

Network timeouts. The API call starts but the carrier's server does not respond within the allowed time window. Treat these the same as carrier system errors: retry, then fall back to portal submission. Log the timeout with a timestamp.

Schema version mismatches. The carrier updates their API to a newer ACORD schema version without providing adequate notice. Your integration sends data in the old format and the carrier rejects it. This is rare but significant. Monitor carrier developer portal announcements and build schema version checking into your integration to catch mismatches before they affect submissions.

Implementation Steps with Realistic Timelines

Step 1: Carrier panel mapping (Week 1). List your carriers by premium volume. Determine which tier each falls into. Check each Tier 1 carrier's developer portal for API documentation. Identify the highest-volume Tier 1 carrier as your starting point.

Step 2: Register for API access (Weeks 2-4). Submit the API access application through the carrier's developer portal. Provide agency credentials, appointment documentation, and your technical contact. Follow up at day 10 if you have not received confirmation. Approval typically takes 2-3 weeks.

Step 3: Review API documentation and sandbox environment (Weeks 2-4, parallel). While waiting for credentials, study the carrier's API documentation. Map their required fields against your AMS's available data. Identify any fields the carrier requires that your AMS does not store, and decide how to handle each gap (manual entry override, default value, etc.).

Step 4: Build field mappings (Weeks 4-6). With sandbox credentials in hand, configure the field mapping in your form tool or AMS. Submit test transactions against the sandbox. Validate that every required field populates correctly. Document fields that require manual override for this carrier.

Step 5: End-to-end testing (Weeks 6-8). Submit a complete set of test transactions covering: new business application, renewal, policy change, and cancellation. Verify that the carrier's sandbox returns the expected responses (quote, acknowledgment, rejection with explanation). Confirm that error handling works correctly for deliberate test failures.

Step 6: Go live with one carrier (Week 8). Switch production submissions for this carrier from portal upload to API. Monitor daily for the first two weeks. Compare error rates and turnaround times to the portal upload baseline.

Step 7: Expand to additional carriers (Weeks 9+). Once the first carrier integration is stable, begin registration for the second carrier. Each subsequent integration reuses the AMS-side infrastructure. The primary new work is carrier-specific field mapping and testing.

ROI Calculation for High-Volume Agencies

The ROI case for API integration is strongest at agencies processing 200 or more submissions weekly. At 200 submissions per week, the time difference between portal upload (10-15 minutes each) and API submission (under 2 minutes) equals 25-43 hours per week. At a $32/hour blended CSR rate, that is $800-$1,376 per week in labor savings, or $41,600-$71,552 annually.

Implementation cost for the first carrier integration typically runs $8,000-$15,000, including middleware or AMS configuration, field mapping, testing, and staff training. Payback occurs in 8-20 weeks depending on submission volume. Each additional carrier integration costs $3,000-$6,000 because the AMS-side infrastructure is already built.

At 100 submissions per week, the time savings are still significant but the payback period extends. For agencies in the 50-100 weekly submission range, the decision depends on how many Tier 1 carriers are on the panel and whether those carriers represent the majority of premium volume.

API Integration and Claims-Made vs. Occurrence Form Handling

ACORD API integrations must account for differences in coverage form types that affect the data structure of the submission.

Claims-made forms require three fields that occurrence policies do not: retroactive date, prior acts coverage indicator, and extended reporting period (tail) options. In ACORD XML, these fields sit inside the CovTerm element under the liability section. Your field mapping must populate these fields when the submission is for a claims-made policy and leave them out of the payload entirely for occurrence policies. Sending empty or null values for retroactive date on an occurrence submission causes validation failures at some carriers.

Occurrence forms require per-occurrence and aggregate limit fields in specific schema positions within the Liability element. These must be populated with actual dollar values, not placeholder zeros. Carriers reject submissions where coverage limits do not meet their underwriting minimums, and the error message returned typically cites the specific limit field that failed.

Form-type-specific field logic is one of the reasons off-the-shelf middleware is useful for agency API integration. Building conditional field logic from scratch for every carrier is time-consuming. Middleware platforms that specialize in insurance data exchange pre-build this logic and maintain it as ACORD schemas update.

Monitoring API Integration Health

An API integration that worked at go-live can break months later due to credential expiration, carrier schema updates, or AMS upgrades. Build a monitoring protocol from day one.

Daily submission status review. Every morning, check the API submission log for the previous day. Verify that every submission has a successful acknowledgment from the carrier. Any submission without an acknowledgment requires immediate follow-up.

Weekly error rate tracking. Track error rate per carrier per week. An error rate above 2% for an established integration signals a data quality or mapping problem. An error rate that spikes suddenly signals a schema change or credential issue.

Monthly credential check. Verify that API credentials for each carrier have at least 60 days remaining before expiration. Contact the carrier's API support team to renew 30 days before expiration.

Quarterly schema version review. Check each carrier's developer portal for schema version updates. ACORD releases updates annually; carriers release carrier-specific updates on their own schedule. A schema version mismatch is not obvious until submissions start failing.

FAQ

What is ACORD forms API integration and how does it work?

ACORD forms API integration is a direct machine-to-machine connection between your agency management system and a carrier's underwriting platform. When a CSR initiates a submission, the AMS packages the client and coverage data into an ACORD-standard format (XML or JSON) and sends it to the carrier's API endpoint over an encrypted HTTPS connection. The carrier's system receives the data, validates it against their underwriting rules, and returns a response (acknowledgment, quote, or error message) without any human involvement on the carrier side. The entire exchange takes seconds to minutes, compared to the 5-7 day round-trip for email PDF submissions.

Which AMS platforms support ACORD forms API integration in 2026?

Applied Epic supports outbound API submission natively through its IVANS Exchange connections and Applied Technology Exchange (ATX) developer framework for custom integrations. Vertafore AMS360 supports API submission through its BriteLines integration layer and the Vertafore Open Platform (VOP) marketplace. HawkSoft supports API connections through its HawkLink framework, primarily for quoting integrations. AMS platforms that do not support native outbound API calls can use middleware platforms that sit between the AMS and the carrier, receiving data via export or ODBC and reformatting it as an API call. No AMS platform supports API integration with every carrier; check each carrier's developer portal for which AMS platforms appear in their supported integrations list.

How long does it take to implement ACORD forms API integration for a single carrier?

The typical timeline for the first carrier integration is 6-10 weeks from start to go-live. This includes 2-4 weeks for carrier API access approval, 2-4 weeks for field mapping and sandbox testing, and 1-2 weeks for end-to-end testing before production launch. Each subsequent carrier integration takes 3-5 weeks because the AMS-side infrastructure is already in place and only carrier-specific field mapping and testing remain. Agencies working with a middleware platform that has pre-built carrier connections can cut these timelines by 50%, since the field mapping and schema handling are done by the platform rather than the agency's technical team.

What happens when an API submission fails?

When a carrier's API rejects a submission, it returns an error code and a message identifying the specific cause. Validation errors (missing required field, value out of range, format mismatch) resolve with CSR correction and resubmission, typically in under 5 minutes. Authentication errors (expired API credentials) require contacting the carrier's API support team to renew access. Carrier system errors (server-side failures) trigger automatic retry logic that resubmits after 15-30 minutes. If three retry attempts fail, the system should alert the responsible CSR and queue the submission for portal upload as a fallback. All failures must be logged with timestamps and error details for audit and troubleshooting purposes.

How does API integration handle the difference between claims-made and occurrence policies?

ACORD XML and JSON schemas include conditional fields that appear only for specific coverage form types. Claims-made forms require retroactive date, prior acts indicator, and extended reporting period fields within the liability section of the submission. Occurrence forms require per-occurrence and aggregate limit fields in specific schema positions. Your field mapping must detect which form type applies to each submission and populate only the fields relevant to that form type. Sending claims-made-specific fields in an occurrence submission or vice versa causes validation failures at most carriers. Well-configured middleware and form tools handle this conditional logic automatically based on the coverage form selected in the AMS.

What is the minimum submission volume where API integration makes financial sense?

API integration typically makes financial sense for agencies processing 100 or more ACORD form submissions per week, provided at least 30-40% of that volume goes to Tier 1 carriers with documented APIs. At 100 weekly submissions to Tier 1 carriers, the time savings (13+ minutes per submission compared to portal upload) generate roughly $2,200-$3,400 in monthly labor savings. Implementation cost for the first carrier integration runs $8,000-$15,000, producing payback in 3-6 months. Below 100 weekly submissions or with a carrier panel dominated by Tier 2 and Tier 3 carriers, portal-based electronic submission delivers better return relative to implementation complexity. Revisit the API decision annually as carrier adoption expands.

---

Written by Javier Sanz, Founder of BrokerageAudit. Last updated April 2026.

Compare AMS platforms and carrier API tools side by side. See the full comparison at BrokerageAudit