What Is a Requisition ID in ATS Workflows

A requisition ID is a unique alphanumeric tracking code for a specific job opening, connecting that role across your ATS, career site, and external channels such as LinkedIn. It identifies the role throughout its hiring lifecycle, while related systems may use separate IDs for individual openings, candidates, or applications.

A recruiter in Mexico City might be coordinating a remote software engineering role for candidates in Bogotá, São Paulo, and Buenos Aires. The same position may appear on the company career site, LinkedIn, and a regional job marketplace. Without a stable identifier, those channels can create duplicate listings, misroute applications, or return incomplete reporting.

The requisition ID prevents that confusion. It gives recruiters, hiring managers, HR operations teams, and integration partners one durable reference for the role. The important distinction is simple: the requisition is the business request to hire, while the requisition ID is the system reference that lets people and software find and manage it.

The Core Purpose of a Requisition ID

A requisition ID starts with an approved hiring need and stays attached to the role as it moves through the ATS. In recruiting integrations, it acts as the identifier that lets downstream systems and partners match the same job opening across platforms, as documented in Greenhouse's explanation of requisitions and openings.

Consider a hiring manager who receives approval to add a backend engineer to a distributed team. The requisition record may contain the department, hiring manager, location, employment type, budget information, job description, and approval history. The requisition ID ties those fields together so the recruiter can publish the role, review candidates, pause hiring, and close the position without losing the original context.

That continuity matters for nearshore hiring. A company hiring engineers in Mexico City and Colombia may use similar job titles across regions, but each approved role still needs its own reference. The title “Senior Software Engineer” isn't enough to distinguish location, business unit, compensation framework, or headcount plan.

Practical rule: Treat the requisition ID as the role's durable address. Don't use the job title as a substitute.

The ID also connects operational events that happen after publication. Approval status, posting status, candidate activity, interview stages, offer progress, and closure can all point back to the same requisition record. In well-managed systems, this makes the ID useful for audit trails and reporting because teams can reconstruct what happened to the hiring request.

Candidates usually don't need to understand this architecture to apply. Recruiters do. If an applicant in Lima follows up with a hiring manager in Austin, the requisition ID can help both sides confirm they're discussing the same opening, particularly when similar roles are active in several countries. For broader context on structuring hiring workflows across the region, see this guide to hiring in Latin America.

System Anatomy and Numbering Formats

A requisition ID can look simple in a user interface, but enterprise systems often separate the value people read from the key the application uses internally. Oracle's procurement documentation illustrates this pattern by distinguishing a human-readable requisition number from an internal requisitionHeaderId. The first supports recruiter, buyer, or manager interactions. The second protects database integrity and links records reliably inside the application, as shown in Oracle's requisition data model.

The visible value may be numeric, alphanumeric, or formatted with letters and symbols, depending on system settings. It isn't necessarily a code that explains the department, country, or seniority level. In many implementations, it's just an identifying label used to retrieve the correct record, a distinction also described in this purchase requisition explainer.

Automatic numbering versus manual entry

Some platforms generate IDs automatically. Deltek Costpoint, for example, can increment the next available requisition number when system numbering is enabled. When manual numbering is selected, the requester must enter an ID before saving and is responsible for keeping it unique, according to Deltek's requisition numbering documentation.

Automatic numbering usually works better for large, distributed hiring teams because it reduces collisions. Manual numbering can still be useful when an organization needs a legacy convention, a finance reference, or a migration-compatible format. The trade-off is governance. A manually entered code may be duplicated across business units, mistyped during an export, or changed to satisfy a downstream mapping rule.

PeopleSoft and other enterprise systems also use the requisition ID as a central lookup key for requisition details and audit tracking. Some older enterprise documentation describes requisition IDs with a limit of 10 alphanumeric characters, while Greenhouse documents a configurable requisition ID that may be manually entered or generated and has a 50-character limit in its workflow documentation. These are system-specific constraints, not universal industry standards. Check the actual configuration of your ATS before designing an integration format.

Before connecting an ATS to a career site or external channel, document four points:

• Visible field: Which value recruiters and candidates can see.
• Internal key: Which immutable field the application uses.
• Generation rule: Whether the system creates the ID or a user enters it.
• Uniqueness scope: Whether uniqueness applies globally, by company, or only within a business unit.

That inventory prevents a common implementation error: mapping an integration to a convenient display field when the partner expects the stable requisition reference.

Requisition IDs Versus Opening and Job IDs

ATS exports often contain several identifiers for one hiring initiative. They aren't interchangeable.

A requisition ID normally identifies the approved hiring request or parent role. An opening ID identifies a specific slot under that requisition when the organization is hiring multiple people against one request. A job ID is a broader term that may refer to the public posting, a platform-specific record, or an internal role identifier. Its meaning depends on the ATS and the integration contract.

Greenhouse documents this parent-child structure directly. One requisition can contain multiple openings, with each opening receiving its own Opening ID. That distinction matters when a company approves several hires for the same role, such as multiple senior developers assigned to Colombia, but needs to track each position separately during fulfillment.

Identifier TypePrimary FunctionDownstream ImpactRequisition IDIdentifies the approved hiring request or parent roleAnchors approvals, reporting, postings, and integration referencesOpening IDDistinguishes an individual position under one requisitionSupports slot-level tracking when several hires belong to the same requestJob IDIdentifies a public or system-specific job recordMay control posting, URL structure, or channel-level synchronizationCandidate or application IDIdentifies a person or their applicationConnects an applicant to a process, not to the hiring request itself

The mapping decision recruiters should make

Before sending data to a partner, ask what the receiving system needs to identify. If it needs the role as a whole, the requisition ID may be appropriate. If it needs to distinguish individual headcount slots, the Opening ID may be required. If it controls a public listing, the partner may expect its own job ID while retaining the requisition ID as a source reference.

Confusing these fields can produce subtle failures. Applications may attach to the wrong role, reports may count one requisition as several unrelated jobs, and a closed opening may continue receiving candidates because the public job record remains active. Diversity and regional reporting can also become unreliable if one parent requisition is incorrectly treated as the only operational unit.

Integration test: Create a requisition with multiple openings in a non-production environment, then confirm which identifier appears in the posting feed, application record, reporting export, and closure event.

This test is more valuable than assuming that a field named “job ID” means the same thing in every platform. Global hiring stacks often combine an ATS, HRIS, payroll system, career site, and external distribution tools. Each may assign its own identifier, so the mapping document should name the source field and destination field explicitly.

Powering External Distribution and Job Wrapping

A requisition ID becomes especially important when an ATS distributes jobs to external channels. The receiving platform needs a unique reference to determine whether a role is new, already posted, updated, paused, or closed. Without that reference, a revised feed can look like a second job rather than an update to the existing one.

LinkedIn's integration guidance describes the ATS requisition ID as the field used to match a job between the ATS and LinkedIn during job wrapping. Microsoft's documentation also requires a unique job requisition ID within the ATS for this type of integration, as explained in LinkedIn's job requisition ID guidance.

The practical workflow is straightforward. The ATS creates or stores the requisition, the career site publishes the role, and the external platform receives the job data alongside the identifier. When the ATS later changes the status or content, the external channel uses the same reference to update the existing listing instead of creating another one.

Where global integrations break

The difficult cases involve cloned requisitions, regional systems, and overlapping numbering schemes. SAP documentation notes that a requisition ID may need an integration code appended to prevent collisions across systems. That can create a mismatch if one platform stores the original ID while another expects the transformed value.

Don't solve this by casually editing the visible ID after publication. Instead, define whether the integration uses the source value, a normalized value, or a composite identifier. Record that rule in the feed specification and test updates, reopening, closure, and regional duplication scenarios.

Programmatic distribution creates the same requirement at greater scale. Teams working with programmatic job ads should ensure that the campaign layer doesn't generate a new identity for every channel variation. One role can have multiple distribution treatments, but the source requisition reference should remain traceable.

Visibility and Usage for Candidates and Recruiters

Candidates usually encounter a requisition ID on a job page, application confirmation, recruiter email, or portal status screen. It may appear beside the title, location, or reference information, but it isn't normally a candidate-facing credential or a substitute for an application ID.

For a recruiter, displaying the ID can improve communication. A candidate in Buenos Aires might apply to several roles with similar titles, while the hiring manager is reviewing openings across Argentina and Brazil. Including the reference in follow-up messages helps the recruiter identify the exact posting without asking the candidate to resend the full job description.

Guidance for employers

Publish the requisition ID when candidates are likely to contact the company about a specific role. Keep it read-only on the career site, and make sure the value shown publicly corresponds to the record used for inbound applications. If privacy or security policy limits public exposure, include it in confirmation messages instead.

Recruiters should also distinguish the requisition ID from the candidate's application ID. The former identifies the job. The latter identifies the person's submission. Mixing them in email templates creates avoidable confusion for recruiting coordinators and support teams.

Guidance for candidates

You don't need to add a requisition ID to a cover letter unless the employer asks for it. If you contact a recruiter, include the exact job title, location, application date, and visible requisition reference when available. That combination is useful when a company has related software engineering roles in São Paulo, Mexico City, or Santiago.

The ID also won't reliably track your application status across employers. Use the portal's application reference for candidate-specific questions, and treat the requisition ID as the identifier for the role itself. Clearer application messages support a better experience, which is why recruiters should follow practical candidate experience best practices.

Maintaining Data Integrity Across the Hiring Lifecycle

A requisition ID isn't a set-and-forget label. Its value depends on remaining unique, stable, and correctly mapped as the role is edited, cloned, reopened, migrated, or distributed across systems.

Manual numbering creates direct collision risk because users must maintain uniqueness themselves. Deltek's documentation distinguishes system numbering from manual numbering, while Greenhouse allows organizations to configure requisition IDs according to their workflow. Neither approach is automatically safe. Automatic generation can conflict with migration logic, and manual conventions can fail when multiple regional teams create records independently.

Rules that hold up in practice

• Don't reuse closed IDs. A new headcount should receive a new requisition reference, even when the title and hiring manager are unchanged.
• Separate cloning from reopening. Reopening the same role may preserve the original business context, while a cloned requisition represents a different record and should be governed accordingly.
• Freeze the integration value. If a partner requires a stable identifier, don't alter it to fix a formatting issue. Transform the value in a documented integration layer.
• Map parent and child fields explicitly. Store the relationship between requisition ID and Opening ID instead of forcing one field to serve both purposes.
• Audit status transitions. Verify that active, paused, and closed states reach every connected channel consistently.

A useful audit starts with a sample of recently created, reopened, cloned, and closed requisitions. Compare the visible ID, internal key, opening references, public job record, and application records. Look for duplicate values, broken parent-child relationships, and listings that remain active after the source record closes.

For candidates, stable identifiers also support cleaner application tracking. If you're trying to avoid being lost in a poorly configured ATS, this practical guide to beating the resume black hole offers useful context on how application systems process submissions.

LatoJobs connects professionals in Argentina, Brazil, Mexico, Colombia, Chile, Peru, and other Latin American markets with remote, hybrid, and onsite roles from regional and global employers. Browse the LatoJobs marketplace to find relevant opportunities, filter by location and function, and keep the correct requisition reference when you apply.