uphold / docs Goto Github PK

Affected endpoints:

• /v0/reserve/transactions
• /v0/reserve/ledger
• /v0/me/transactions
• /v0/me/cards/:card/transactions

The current title, "Time-Based One-Time Password (TOTP)", is getting truncated in the navigation sidebar:

Could we come up with a shorter title that won't get truncated?

The documentation should mention the PATCH /me endpoint and what fields are available for updating.

Is there a plan to add a sandbox API, or tokens, to make it possible to commit a transaction without loosing money to the transaction fees, for testing purposes?

For example, when using the new transactions:transfer:application, the only destination that is allowed is the application's clientId.

This table should describe debit and credit card deposits and withdrawals.

Not all addresses may be available for all cards. For example, only VOX cards have a voxel address. This should be reflected in the documentation.

The documentation should be updated to highlight the fact that X-RateLimit-* headers will be renamed, and all the older names' occurrences should be replaced accordingly.

For example,
https://uphold.com/en/developer/api/documentation/[email protected]

Recently I tried to authenticate using my sandbox business user by client credentials flow. I did the following request

curl -X POST https://api-sandbox.uphold.com/oauth2/token \
>   -H "Content-Type: application/x-www-form-urlencoded" \
>   -u <client-id>:<client-secret> \
>   -d 'grant_type=client_credentials'

But I receive as response

{"error":"unauthorized_client"}

Could anyone please help me with this? Thanks!

Most errors responses I see from the API are in this format:

{"code":401,"error":"invalid_token","error_description":"The access token provided is invalid."}

However, I just noticed that when attempting to create an invalid transaction, I get an error of a different format:

# Note that I used a wrong value for the destination field

curl "https://api.bitreserve.org/v0/me/cards/OMITTED_CARD_ID/transactions" \
  -X POST \
  -H "Authorization: Bearer OMITTED_TOKEN" \
  -d "denomination[currency]=BTC&denomination[amount]=0&destination=this_email_does_exist"

{"code":"validation_failed","errors":{"destination":[{"code":"invalid","message":"This value is not valid"}]}

Is this intendend?

The main advantage is improving diffs and review of prose stored in version control, as well as clarifying sentence structure in the source (non-rendered) mode.

More info: Semantic Linefeeds (blog post motivating this practice); Semantic Line Breaks (specification).

The documents state that a card entity has a position attribute. But instead, the current JSON I'm getting has a settings attribute, which in turn has position and starred

Which one of these is the correct one?

Right now just some of the tickers are available for public consumption. It would be nice to get all of the combinations, especially when asking for the ticker to a specific currency.

Any plans for this?

Thanks.

Hey, apologies if this is a stupid question, I wanted to script some trades with my Uphold account, as I'm not a corporate partner, PAT tokens seemed to be the best fit. However, in order to create a PAT token, you seem to need a normal Bearer token. However, I can't see how to get a Bearer token, unless you register an app, which I thought was for the corporate partners etc? I can see you used to be able to use your username and password to create a PAT token but it was removed?

It seems this endpoint accepts not only a card id, but also a bitcoin address id. I tested it with the following values:

• 1LbHhVFjLeC3hVhW4FXrwu7MNUCkoGTwA5
• 2daa59e8-89c5-4cbe-99fc-f66435024bcf

And for both of them I get the same result:

@address={"bitcoin"=>"1LbHhVFjLeC3hVhW4FXrwu7MNUCkoGTwA5"},
 @addresses=[{"id"=>"1LbHhVFjLeC3hVhW4FXrwu7MNUCkoGTwA5", "network"=>"bitcoin"}],
 @available="0.001",
 @balance="0.001",
 @currency="XAU",
 @id="2daa59e8-89c5-4cbe-99fc-f66435024bcf",
 @label="XAU card",
 @last_transaction_at="2014-12-02T00:29:45.507Z",
 @position=7>

I realize this is probably intended, but shouldn't it be documented as well?

The returned information for transactions doesn't match the entity description. And even between different methods for getting transaction(s), the values are slightly different

• List Card Transactions Doesn't have type
• Get All Transactions (Public) has a quotedAt which I don't see documented anywhere (what is it?) and doesn't have type
• Get Transaction (Public) I would assume it returned the same values as the one above, but it doesn't look like it, from the docs

There are possibly other cases I didn't check (like Create Transaction)
I also didn't check if the actual returned JSON has the same inconsistencies. This was just by looking at the docs

I also understand that some of these values might not make sense under the context of certain endpoints, which is OK, but it doesn't look like that's the case for all of them

It would be more convenient (and discoverable) if these docs were available at https://docs.uphold.com, in addition to the current URL https://uphold.com/en/developer/api/documentation/.

Each time i'm trying to transfert all the money from a single card i have got this error : denomination: validation_failed probably because the value has changed after my last check.

How can i transfert all the money from a single card ?

Thanks for your time !

Port from here.

https://uphold.com/en/developer/api/documentation/#transaction-object

Instead of:

In case a transaction is coming in from the outside, how many confirmations have been received.

we should have something like:

In case of a external transaction (deposit/withdrawal), reflects the progress percentage (between 0.0 and 1.0).

The OAuth documentation refers to an "expires" key in the returned object but the actual spec-compliant name is "expires_in".

It would be nice to have a public status page for the API.

See this conversation for context.

The current error documentation could be improved by stating the actual object structure of the errors, as well as clearly stating the reasoning and distinction between the OAuth errors and the application errors.

Refs #38.

Card-related endpoints now contain a normalized key that contains the available and balance in every supported currency.

Links and access token examples are still named with Bitreserve. As soon as the migrations are finished these should be changed to correspond to Uphold.

The endpoint for getting a token is /oauth2/tokens, making it the only one without the version prefix.

Is there a way to make it work with the version, or is it really an edge case and no way around it?

I'm needing the ability to send XRP to an address plus the destination tag. The destination tag isn't an option

The documentation should be updated to highlight the fact that the X-Uphold-Request-Id header will be renamed, and all the older name occurrences should be replaced accordingly.

The documentation for creating transaction its not clear for scenarios where the origin is specified, rather than the destination. For instance ACH accounts.

https://uphold.com/en/developer/api/documentation/#create-amp-commit-a-transaction

I would suggest separating the create into the two cases:

1. Transactions from the card (setting destination)
2. Transactions to the card (setting origin)

Thanks

It would be useful to add a section to the developer docs that states the official policy on advance warning for breaking changes. (is it one week? two weeks?)

Also, how will this process happen? Will the changes be fully documented a week before they are deployed?

Apologies for asking such a basic question, but by following the docs I'm just going round and round in circles.

How do you create an API key?

I'm not writing an application for the public, I just need to use the API.

The cards property provided in user objects returned from the API will be removed soon. The documentation should be updated accordingly.

The /me/cards endpoint supports filtering by currency but that is not reflected on the Doc.

Here is an example of the filter:

GET /v0/me/cards?q=currency:BAT

The documentation should be updated with all the fields that are supported for filtering.

Safari doesn't seem to be highlighting the correct item in the sidebar while scrolling through the developer docs.

See: https://developer.bitreserve.org/en/community#!/bitreserve-developer/general%23list-card-issue-in-android

A developer has asked if we support retrieving a list of transactions that is filtered by type. This would be super helpful I think for a number of reasons. I wonder if implementing a new search endpoint would be a better approach? It might be more logical in some respects.

Many of the images linked to here https://uphold.com/en/developer/api/documentation/#resources

take users to a 404. Try for example Small Size for the 1st two buttons.

The documentation should be updated to highlight the fact that X-Bitreserve-OTP-* headers will be renamed, and all the older names' occurrences should be replaced accordingly.

The Uphold sandbox environment returns static ticker rates. This should be made clear in the documentation.