Unable to Fetch Cards by Card URI [UNAUTHORIZED_ACCESS Error]

[shareably]

The Card Fetch API is not working for our ad account. The problematic request:

https://ads-api.twitter.com/4/accounts/18ce53x1e75/cards?card_uri=card://1044713018989236225

is failing with UNAUTHORIZED_ACCESS. The following requests both succeed:

https://ads-api.twitter.com/4/accounts/18ce53x1e75/
https://ads-api.twitter.com/4/accounts/18ce53x1e75/cards/all/69ay2

Which leads me to believe that (1) we are authenticated correctly and (2) we have access to the card. Therefore I’m not sure why the above request would fail.

The full response is as follows:

Body

{
    "errors": [
        {
            "code": "UNAUTHORIZED_ACCESS",
            "message": "This request is not properly authenticated"
        }
    ],
    "request": {
        "params": {}
    }
}

Response Headers:

content-disposition →attachment; filename=json.json
content-encoding →gzip
content-length →139
content-type →application/json;charset=utf-8
date →Thu, 27 Sep 2018 00:01:20 GMT
server →tsa_a
strict-transport-security →max-age=631138519
x-api-version →4.0
x-connection-hash →b11cad1f44056adca7e984016b933a8a
x-content-type-options →nosniff
x-current-api-version →4.0
x-frame-options →SAMEORIGIN
x-response-time →10
x-runtime →5.5E-5
x-transaction →0062b761008a2806
x-xss-protection →1; mode=block; report=https://twitter.com/i/xss_report

[juanshishido]

Thanks for the question and for providing these details, @shareably! It helps a lot that you also let us know that both the GET accounts/:account_id and the GET accounts/:account_id/cards/all/:card_id requests succeeded.

For the unsuccessful request, it’s likely that reserved characters are not being properly encoded.

Ensure that you’re encoding reserved characters appropriately within URLs and POST bodies before preparing OAuth signature base strings.

Source

Please let us know if encoding the reserved characters this resolves the issue.

Thanks again!

---

For reference for other users who may come across this post, see this thread for general information about UNAUTHORIZED_ACCESS issues.

[shareably]

Hmm, I originally thought that this was the issue so I encoded the string manually before sending, but it didn’t solve the issue. I’m not rolling my own request infrastructure to encode parameters and am using an OAuth library to handle the signature base strings so those should be working as well.

I’ll give it another go and report back. In the meantime let me know if there’s anything else you can think of that might be causing this behavior.

[shareably]

Looks like it’s working this time around! I guess I had made a mistake previously, thanks for calling attention back to it.

[juanshishido]

Glad to hear it’s working!