0

Clarification on the url parameter in B-Deploy API (/setup vs /player)

Hi everyone,

 

I’m leveraging the B-Deploy API and noticed the url field appears in the POST payloads for both the /setup and /player endpoints. We populate this field with a time-limited, signed S3 URL that hosts our deployment package.

 

I’d appreciate some guidance on three points:

 

  1. Functional differences – Does the url parameter behave identically in /setup and /player, or are there subtle differences in how each endpoint processes it?

  2. Use cases – In practice, when should we target /setup versus /player for a deployment triggered via a signed URL?

  3. URL expiry – What happens if the signed S3 URL expires before the player finishes downloading the package? Does the B-Deploy service retry, cache, or surface an error we can catch?

 

 

Understanding the intended workflow will help us choose the right endpoint and set an appropriate expiry window for our signed URLs.

 

Thanks in advance for any insights or best practices you can share!

2 comments

  • -1
    Avatar
    omder21

    The `url` parameter in both B-Deploy API endpoints, `/setup` and `/player`, provides the location of your deployment package via a signed S3 URL, but they process it differently based on their deployment stage. `/setup` is typically for initial configuration and complex packages, while `/player` is for direct application updates and simpler deployments. When using signed URLs, choose the e-zpassny endpoint based on your deployment needs. If the signed S3 URL expires before the player finishes downloading, the download will likely fail, and the B-Deploy service won't automatically retry or generate a new URL. Therefore, it's crucial to set a sufficiently long expiry window and implement error handling with potential retries in your application logic.

  • 0
    Avatar
    Panos Rapo

    Did you just use AI to come up with that answer? What does the NY tolls have to do with this?

Please sign in to leave a comment.