Every GitHub Object Has Two IDs

Why It Matters

Understanding the dual ID scheme lets developers reliably map GraphQL node IDs to REST URLs, simplifying integration and avoiding costly database migrations. It also clarifies how GitHub’s backend encodes object scope, improving debugging and tooling.

Key Takeaways

• GitHub uses both global node IDs and integer database IDs
• New node IDs encode data via MessagePack, then Base64
• Database ID resides in lower 32 bits of decoded value
• Legacy IDs follow “enum:TypeID” plain text format
• Extracting IDs avoids costly migrations for third‑party tools

Pulse Analysis

GitHub’s API exposes two parallel identifier schemes: the traditional integer database IDs that appear in REST URLs, and the newer global node IDs returned by GraphQL. The node IDs are opaque strings that begin with a type prefix (e.g., PRRC_) followed by a Base64‑encoded payload. Decoding that payload reveals a 96‑bit binary value, where the lower 32 bits correspond to the original database ID. Further analysis shows the payload is a MessagePack‑packed array, typically [0, repository_id, object_id], allowing the platform to keep IDs globally unique while preserving backward compatibility with legacy formats that embed a simple “enum:TypeID” string. For developers building integrations, this dual system can cause confusion when linking GraphQL objects to REST endpoints. By applying a straightforward Base64 decode and a bitmask, or by unpacking the MessagePack array, the integer ID can be extracted without any data migration. This technique saves time and resources for tools like code‑review assistants, CI pipelines, or analytics dashboards that need to correlate comments, pull requests, and issues across APIs. It also highlights why some older repositories still return the legacy “010:Repository12345” pattern, reflecting GitHub’s incremental rollout. The practical takeaway is to treat GitHub node IDs as opaque identifiers in production code, but retain a lightweight utility for reverse‑engineering when URL construction or cross‑API mapping is required. Understanding the underlying structure helps debug edge cases, especially in mixed environments where both legacy and new IDs coexist. As GitHub continues to evolve its internal serialization, developers should monitor the migration guide and anticipate future changes, while relying on stable, version‑agnostic API fields to maintain robust integrations.