FAR and DFARS API: Government Contract Clauses You Can Query by Number

If you build govcon software, you can pull a FAR or DFARS clause by its number over an API and get structured JSON back. The Vaquill AI corpus carries 5,537 FAR sections (48 C.F.R. chapter 1), 2,877 DFARS sections (48 C.F.R. chapter 2), and 397 DFARS PGI documents across 47 Parts. The FAR and the DFARS refresh daily as part of the CFR. The PGI refreshes weekly, on a different track, because it is a different kind of document: guidance for contracting officers, not regulation that binds a contractor. Getting that last distinction wrong is a real compliance mistake, so most of this post is about it.

TL;DR

• Three layers, two corpora. FAR and DFARS live inside corpusType: "CFR", filterable with source=far and source=dfars. The DFARS PGI lives in corpusType: "AGENCY_GUIDANCE" with source=dfars_pgi.
• The PGI is guidance, not regulation. It tells a contracting officer how to carry out what the DFARS requires. Treating a PGI paragraph as a binding contractor obligation is the mistake this post exists to prevent.
• FAR and DFARS are a chapter split of Title 48 data you already have, not extra sections. Turning on the filter does not add coverage, it narrows it.
• You can cite a clause directly. FAR 52.219-14 and DFARS 252.225-7001 both resolve, because clause numbers are unique across Title 48 by design.
• Clause flow-down works as resolve-once, batch-forever. Resolve each prime clause to a stable actId, store it, then refresh up to 50 at a time with one call.
• Two cadences, two meanings. A DFARS text change reaches you within a day. A PGI change reaches you within a week. When the PGI moves and the DFARS does not, implementation practice changed and your obligation did not.

Filed under our US primary law corpus series, which covers the corpus source by source.

Title 48 is a chapter split of the corpus in CFR API: 219,114 Federal Regulation Sections, Refreshed Daily, so start there. Then Federal Register API: Querying 202,526 Final and Proposed Rules for acquisition rules before codification, and Export Controls API: BIS Advisory Opinions and DDTC Commodity Jurisdiction Determinations for the export side.

The three layers, precisely

The FAR and the DFARS are codified regulation. They sit in the Code of Federal Regulations, they went through notice and comment, and a clause becomes an obligation when it is incorporated into your contract.

The PGI is procedural guidance published by DoD for its own acquisition workforce. It cites as PGI 225.370. It tells a contracting officer how to do the thing the DFARS requires: which form to use, what to document, when to consult someone.

There is a useful signal in the split, too. When the PGI moves and the DFARS does not, what changed is how the government intends to administer an existing rule. Your obligation is the same. How your contracting officer will exercise it is not.

FAR and DFARS are a chapter split, not extra data

This one is worth being blunt about because vendors inflate coverage this way.

Title 48 of the CFR is the Federal Acquisition Regulations System. Chapter 1 is the FAR. Chapter 2 is the DFARS. Both are already inside the 219,114 CFR sections the corpus carries. The source filter splits that existing Title 48 data by chapter. It does not add a single section.

So source=far is a convenience, not a coverage claim. What it buys you is a clean scope: search "limitation on subcontracting" across source: "far" and you are searching the FAR and nothing else, without knowing which part the answer sits in.

The numbering underneath is what makes clause lookup work at all. FAR clauses live in Parts 1 through 53. DFARS lives in Parts 201 through 253, plus Part 270. Every other Title 48 chapter, the agency-specific FAR supplements, gets its own disjoint block of part numbers (Commerce's chapter 13 runs Parts 1301 to 1352, for instance).

Because the blocks do not overlap, a clause number is unique across the whole title. That has a practical payoff below.

Two ways to reach a clause

Cite it directly

curl -G https://api.vaquill.ai/api/v1/us/statutes/resolve \
  -H "Authorization: Bearer vq_key_..." \
  --data-urlencode "cite=FAR 52.219-14"

Two credits, on a bearer key issued as the authentication guide describes. You get a resolved verdict plus the full section metadata when it resolves, including the official source URL for the government publisher's own copy of the text.

DFARS 252.225-7001 resolves the same way. So does the plain CFR form, 48 C.F.R. 252.225-7001, since all three name the same record.

Here is the payoff from the disjoint numbering. Contract documents mislabel clause prefixes constantly. A clause list that says "DFARS 52.219-14" is naming a FAR clause under the wrong prefix, which is the kind of typo that breaks a strict parser. Because the number itself is unambiguous across Title 48, that mislabeled cite resolves to the same section the correct label would have. You do not need to sanitize your input's prefixes.

Or search within the scope

curl -X POST https://api.vaquill.ai/api/v1/us/statutes/search \
  -H "Authorization: Bearer vq_key_..." \
  -H "Content-Type: application/json" \
  -d '{
    "query": "domestic end product specialty metals",
    "corpusType": "CFR",
    "source": "dfars",
    "matchType": "phrase",
    "limit": 20
  }'

Four credits per search. matchType: "phrase" is the right setting for acquisition terms of art, where the defined phrase is the whole point and a semantic neighbor is noise.

Send an unrecognized source and you get a 422 that lists every valid code, so the filter vocabulary is discoverable from the error itself. Agency FAR supplements other than the DFARS are not broken out by source; scope those with titleNumber: 48 plus the part you care about.

Clause flow-down, end to end

The real govcon workload is not one lookup. It is: a prime contract arrives with a clause list, and you need current text for every clause, plus a way to know when any of them changes.

Step 1, resolve once. Run each clause number through /us/statutes/resolve and keep the actId. Do this once per clause, not once per contract. A clause number is stable across every contract that cites it.

Step 2, never build ids by hand. For the CFR an actId looks derivable, and that is the trap, which the section id reference spells out. CFR_T17_P240_S240_10b5_1 is 17 C.F.R. 240.10b5-1 with the dots and hyphens flattened, so the pattern seems safe. Elsewhere in the corpus the container segments are not recoverable from a citation, and an assembled id 404s in a way that reads exactly like missing coverage.

The API tells you which failure you hit. Misses come back with notFoundDetail set to assembled_id, with real candidates in didYouMean, or not_in_corpus when nothing matching exists. That diagnosis is free and never charged.

Step 3, batch the refresh. POST /us/statutes/sections takes up to 50 actIds in one call.

curl -X POST https://api.vaquill.ai/api/v1/us/statutes/sections \
  -H "Authorization: Bearer vq_key_..." \
  -H "Content-Type: application/json" \
  -d '{"actIds": ["CFR_T48_...", "CFR_T48_...", "CFR_T48_..."]}'

Cost is 2 credits per section returned, and identifiers with no match are refunded, so a batch of 50 that resolves 47 costs 94 credits rather than 100. Batching is a round-trip and latency win, not a discount. The response preserves the order of actIds and reports misses separately, so you can zip results back onto the ids that produced them.

That endpoint returns metadata and source links. For full text, call GET /us/statutes/section/{actId}/body on the ones you are actually rendering.

Step 4, watch them. Create a watch scoped to your stored actIds with POST /boards/watches. Change events land as refreshes observe them, and the watch's diff endpoint returns before and after text. There is no charge for GET /boards, which lists the watchable sources and stamps each with cadence, lastRetrievedAt, and retrievalStatus, so you can see what you would be subscribing to before you subscribe. Law Change Alerts API: Webhooks for When a Statute or Rule Actually Moves covers the delivery side.

For a per-section history you can read on demand instead of subscribing, GET /us/statutes/section/{actId}/changes costs 1 credit and returns every change our refreshes captured for that section.

Why the two cadences matter to a contractor

A daily CFR refresh means a DFARS clause edit reaches you inside a day. That is the cadence a flow-down pipeline needs, because the cost of shipping a subcontract with stale clause text is a real one you cannot claw back after signature.

A weekly PGI refresh is the right cadence for guidance, because guidance moves less and its consequences are slower. But the difference has a practical edge: during a week when the PGI has changed and you have not pulled it, your read of how a contracting officer will behave is stale while your read of your obligations is current. For proposal teams that is the more common failure, and it is invisible unless you track the two separately.

The third row matters too. Acquisition rule changes appear in the Federal Register before they are codified into Title 48. The Federal Register corpus holds 202,526 agency rule documents from 1994 to the present, filterable by documentType: "final" or "proposed", by agency, and by a publishedFrom/publishedTo window. A proposed DFARS rule is a signal about next year's clause list. The CFR text alone will never show it to you. The CFR API guide works through that reconciliation in more detail.

The limit worth stating up front

Versioning here is the amendment record, not a date parameter. Each citation maps to a single stored text, the current one, and no as_of=DATE parameter exists to ask for an earlier one.

For govcon that limit lands somewhere specific, so be clear about it internally. A contract incorporates clauses as they read on a date, and that date is often not today. This API answers "what does FAR 52.219-14 say now," which is the right question for a new flow-down and the wrong question for a dispute about a 2021 award.

What you get instead:

• amendmentHistory and lastAmendedYear on a section, from the publisher's own credit line.
• GET /section/{actId}/changes, every change our refreshes observed, with detectedAt.
• yearFrom / yearTo on search, a currency filter on the last amendment year the publisher credits.
• Before and after diffs on a watched board, from the point you started watching.

Two cautions. detectedAt is when we saw a change, an upper bound on the effective date, never the effective date itself. And an empty change list means "no captured change", not "never amended", because capture began later than the corpus did and events are swept at 24 months. Every response carries a coverage field saying so, and your UI should render it rather than presenting an empty list as "unchanged".

Where PGI sits among the other agency guidance

AGENCY_GUIDANCE holds 21,906 documents across 34 named sources, each filterable with source=. The PGI is one of them. A few neighbors a govcon or export-control team will recognize:

The DDTC set is the interesting one for a defense contractor: 5,903 commodity jurisdiction determinations, ingested from DDTC's own XLSX export, which is the record of whether a given item fell under the USML or the EAR. Export Controls API: BIS Advisory Opinions and DDTC Commodity Jurisdiction Determinations goes through both sources in detail, and Federal Agency Guidance API: 34 Sub-Regulatory Sources in One Endpoint lists the rest.

Notice the honest windows in that table. BIS advisory opinions run 2003 to 2023. Those bounds are published rather than smoothed over, because a corpus that quietly stops at a date and does not say so is worse than one that admits it.

FAQ

Is the FAR part of the CFR?

Yes. The FAR is chapter 1 of Title 48 of the Code of Federal Regulations, and the DFARS is chapter 2 of the same title. In this API both are inside corpusType: "CFR" and are reached with source: "far" or source: "dfars", or by scoping to titleNumber: 48 and a part.

What is the difference between the DFARS and the DFARS PGI?

The DFARS is codified regulation that can bind a contractor once a clause is incorporated into a contract. The PGI is internal procedural guidance for DoD's acquisition workforce, telling a contracting officer how to carry out what the DFARS requires. The API keeps them in separate corpora, CFR and AGENCY_GUIDANCE, so the two cannot be silently mixed in one result set.

Can I look up a FAR clause by its number?

Yes. GET /us/statutes/resolve?cite=FAR 52.219-14 costs 2 credits and returns a resolution verdict plus the section metadata and the official source URL. Clause numbers are unique across Title 48 because each chapter is assigned a disjoint block of part numbers, so a mislabeled prefix still resolves to the right section.

How many FAR and DFARS sections are there?

5,537 FAR sections and 2,877 DFARS sections. Both counts sit inside the 219,114 CFR sections the corpus already carries, because the source filter splits existing Title 48 data by chapter rather than adding anything new.

How current is the FAR and DFARS data?

The CFR corpus, which holds both, refreshes daily. The DFARS PGI refreshes weekly on the agency-guidance track. GET /boards reports the cadence and last retrieval time for every watchable source, and GET /us/statutes/coverage reports what each corpus is current through in the publisher's own words. Both endpoints are free.

How do I resolve a whole clause list from a prime contract?

Resolve each clause number once with /us/statutes/resolve and store the returned actId. Then fetch up to 50 at a time with POST /us/statutes/sections at 2 credits per section returned, with misses refunded and reported in notFound. Do not build ids from citation strings; assembled ids 404 in a way that looks like missing coverage.

Can I get the FAR as it read on the date my contract was awarded?

Versioning here runs off the amendment record rather than a date parameter. A citation resolves to a single stored text here, the current one, and there is no as_of parameter, so this API answers what a clause says now. For a dispute over an older award you will need an archival source. What you can get here is amendment history, the last amendment year the publisher credits, and the change events captured since our refreshes started watching that section.

Are the agency FAR supplements covered?

The FAR and the DFARS are the two chapters broken out by source. Other Title 48 chapters are reached with titleNumber: 48 plus the relevant part, since each supplement occupies its own disjoint block of part numbers. Check GET /us/statutes/divisions to walk the title's structure before assuming a part range.

Can I get alerted when a DFARS clause changes?

Yes. Create a watch with POST /boards/watches scoped to the clause's actId, and take before and after text from the watch's own diff endpoint. For history that already exists, GET /us/statutes/section/{actId}/changes costs 1 credit and returns every change our refreshes captured, newest first.

Where to start

Read the free endpoints before you spend a credit. GET /us/statutes/coverage, described in the coverage reference, and GET /boards together tell you every corpus count, every publisher currency note, every declared pause with its reason, and every source's last retrieval time. That is the evaluation a primary-law dependency deserves.

We build Vaquill AI, the API in this post, and it is also published as an MCP server if your workflow lives inside an agent rather than a backend. Scope worth knowing up front: this is US primary law, so protest decisions and board of contract appeals opinions come from a separate source. The collection layer is published at open-us-law.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.