Have you changed CURL methods?

Questions
1

Have you made a change to the API regarding curls?
I found that it was much easier to create and debug curls by:
Creating an example CURL in the API.
In my <php?

  • creating a block text base on the example
    $curl=[example template’]
  • replacing the curl variables with my own.
  • then using BackTicks to send the $curl
    $result=`$curl`;

I used this method for Subscriptions, and my subscription curls suddently stopped working.
So changed back to the complex
“curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);….ETC, ETC, ETC

Well I started having trouble curling ORDERS this morning. The <?php Variables $result=`$curl`;
approch which has been working (since at least October) stopped working this morning.

So I compared my $curl code with the same variables plugged into the API explorer
THEY ARE IDENTICAL.

The API verions worked the first time, the $result=`$curl`; failed after many attempts.

Please advise if I have rewrite all my nice simple code.

(I can’t paste the code in here without losing the ‘tabs’ used to format the API version,. If you want to compare the versions (uglified), let me know.

2

:waving_hand: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:

Additional Documentation

Pay for Orders
Test Authorization with Web Server
Test Authorization with Web Server

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

3

It seems like you’re experiencing issues with executing cURL commands in PHP using backticks, which previously worked for you. There hasn’t been any specific change to the Square API regarding cURL commands themselves, as cURL is a standard tool for making HTTP requests and is not directly controlled by Square.

However, there could be several reasons why your approach using backticks might have stopped working:

  1. Environment Changes: Check if there have been any changes to your server environment or PHP configuration that might affect how backticks execute shell commands. This includes changes to PHP settings, server permissions, or shell access.

  2. Error Handling: When using backticks, errors might not be as visible as when using curl_setopt and curl_exec. Consider capturing the output and error messages to diagnose the issue further.

  3. Security Restrictions: Some hosting environments or PHP configurations might restrict the use of backticks for executing shell commands due to security concerns.

  4. API Changes: While the cURL tool itself hasn’t changed, ensure that there haven’t been any changes to the API endpoints or required headers that might affect your requests.

  5. Debugging: Compare the output of your backtick execution with the output from the API Explorer to see if there are any discrepancies in the request or response.

If the backtick method continues to be problematic, it might be more reliable to switch to using curl_setopt and curl_exec, which provide more control and error handling capabilities. This approach is generally recommended for production environments due to its robustness and better error management.

If you need further assistance, consider checking the server logs or enabling verbose output for cURL to get more insights into what might be going wrong.

This answer was reviewed by @Bryan-Square.

4

The working code didn’t chage. My server settings haven’t changed. My non-working code produces identical ‘$curl` to the API curl..
Are you sure something hasn’t changed on your end?

I’ve got about 20-25 curls using my template method. I don’t even know how to test them all.

I got this info from chatGpt
Square has recently tightened:

  • header parsing

  • their rejection of malformed JSON (backticks, unexpanded vars, trailing commas)

  • the requirement to use actual JSON, not “shell-escaped template JSON”

Your template likely was being interpreted incorrectly by PHP before sending; using json_encode() avoids all that.

Did I miss the tech note?
If I had been aware, my production code might now not be failing. Silly me.