Offers

This endpoint updates an existing Offer resource within a specific namespace. It is primarily used during the Design phase of a quote to refine technical specifications, select hardware templates, or adjust product attributes like speed and subnets.

Path parameters

Headers

Request body

The payload is a structured JSON representing the full state of the Offer resource. Key sections include:

Sample request payload

{
    "kind": "offer",
    "version": "v1alpha",
    "namespace": "142034",
    "name": "telr-test-001",
    "metadata": {
        "dateCreated": 1770659951657,
        "dateUpdated": 1770661506547,
        "annotations": [
            "net.gtt.offer/checksum/2e096aa3a1c836fadb745251d0665770c1a7c57d215e784a6c43ac657e62ea0f"
        ]
    },
    "spec": {
        "products": [
            {
                "productSpecification": {
                    "externalId": "access",
                    "productCategory": "connect"
                },
                "attributes": {
                    "type": "dia",
                    "speed": 100,
                    "ipSuffix": "/29"
                }
            }
        ],
        "templateSelection": {
            "highAvailability": 1,
            "firewall": 1,
            "platform": 1,
            "availableTemplates": [
                {
                    "id": "31",
                    "name": "EnvisionEDGE Virtual Router",
                    "platform": "EnvisionEDGE",
                    "max_bandwidth_mbps": 2750
                }
            ]
        },
        "state": {
            "phase": "design"
        }
    }
}

Expected response

• 200 OK: Returns the fully updated Offer object, including a refreshed dateUpdated timestamp.
• 400 Bad Request: Occurs if the payload violates schema constraints (e.g., speed exceeds template limits).
• 409 Conflict: Occurs if the checksum in annotations does not match the current version on the server.

This endpoint performs a partial update to an existing Offer resource using the JSON Patch (RFC 6902) standard. Unlike a PUT request, which requires sending the entire resource, PATCH allows you to modify specific fields—in this case, updating the product configuration without touching other metadata or site details.

Path parameters

Headers

JSON patch operations

The request body uses a list of operation objects. This is a powerful way to ensure atomicity and precision when updating complex nested resources.

Update payload analysis

[
  {
    "op": "replace",
    "path": "/spec/products",
    "value": [ ... ]
  }
]

Response highlights

A successful PATCH returns the fully updated resource.

• Timestamps: The metadata.dateUpdated is refreshed to reflect the patch time (e.g., 1770918180746).
• Integrity: A new net.gtt.offer/checksum is generated in the annotations field. You must use this new checksum for any subsequent PUT or PATCH operations to avoid version conflicts.
• Side Effects: Updating the product configuration may trigger backend recalculations. Notice in the sample response that templateSelection.maxBandwidthMbps has been updated to 100 to align with the new product speed.

Comparison: PUT vs. PATCH

Sample request body

[
  {
    "op": "replace",
    "path": "/spec/products",
    "value": [
      {
        "productSpecification": {
          "externalId": "access",
          "productCategory": "connect"
        },
        "attributes": {
          "type": "dia",
          "speed": 100,
          "ipSuffix": "/29"
        }
      }
    ]
  }
]

This documentation covers the various configurations for the /spec/products array within the GTT Offer API. These payloads utilize the JSON Patch (RFC 6902) standard to replace existing product configurations with specific connectivity types, ranging from wireline Dedicated Internet Access (DIA) to wireless 5G solutions.

Wireline connectivity (DIA)

Used for standard Dedicated Internet Access over fiber or copper. These specifications require defined bandwidth speeds and IP allocation details.

Business Logic: Upgrading speed via PATCH allows for rapid re-quoting of a site without re-entering geographic or site-specific metadata.

Wireless connectivity (5G solutions)

Wireless products are categorized by their Role (Primary vs. Backup) and their Mounting Environment (Indoor vs. Outdoor). Unlike DIA, wireless specifications include an outdoor boolean to determine the necessary hardware and installation type.

5G primary access

Designed for sites where 5G is the main circuit. It typically includes a speed attribute.

• Indoor Primary: Used for standard office environments where the 5G gateway is placed inside.
  • outdoor: false, role: primary, speed: “100”
• Outdoor Primary: Used for sites requiring an external antenna or enclosure to ensure signal integrity.
  • outdoor: true, role: primary, speed: “100”

5G backup access

Designed for failover redundancy. These configurations typically omit the speed attribute as they rely on “Best Effort” wireless delivery during primary circuit outages.

• Indoor Backup: outdoor: false, role: backup
• Outdoor Backup: outdoor: true, role: backup

Attribute dictionary

The following table defines the key fields within the attributes object for all product types:

Implementation example (JSON patch)

To update an offer to an Outdoor 5G Primary configuration, use the following operation:

[
    {
        "op": "replace",
        "path": "/spec/products",
        "value": [
            {
                "productSpecification": {
                    "productCategory": "connect"
                },
                "attributes": {
                    "type": "5G primary",
                    "outdoor": true,
                    "speed": "100",
                    "role": "primary"
                }
            }
        ]
    }
]