CrewAI AMP: valid POST /kickoff returns 401 after required-input validation, no execution created

CrewAI Community Support
1

Hi CrewAI community,

I’m troubleshooting a production AMP deployment where authentication and input validation both work, but a fully populated /kickoff request returns HTTP 401 before any execution is created.

Environment

  • CrewAI version reported by deployment logs: 1.15.21
  • Python: 3.12.10
  • OS: Windows / PowerShell
  • Deployment status: Crew is online
  • Deployment: fs_production_run_v1_v4_structured-output-candidate

Required inputs

Authenticated:



GET /inputs
Authorization: Bearer <TOKEN>

returns:



{
  "inputs": [
    "financial_assumptions",
    "project_name",
    "structure_declaration"
  ]
}

Without a Bearer Token, the same endpoint returns:



HTTP 401
{"detail":"Not authenticated"}

With the Bearer Token:



HTTP 200

Reproduction / validation tests

1. Missing all required inputs



{
  "inputs": {}
}

Result:



HTTP 422
{"detail":"Missing inputs: financial_assumptions, project_name, structure_declaration"}

2. Production payload with project_name deliberately removed

Result:



HTTP 422
{"detail":"Missing inputs: project_name"}

3. Production payload with financial_assumptions deliberately removed

project_name is still present.

Result:



HTTP 422
{"detail":"Missing inputs: financial_assumptions"}

These tests indicate that the same Bearer Token is accepted by /kickoff and that required-input validation is being reached correctly.

Failing production request

The real production request uses the documented top-level inputs object and includes all three required inputs:



{
  "inputs": {
    "project_name": "...",
    "financial_assumptions": {
      "...": "..."
    },
    "structure_declaration": {
      "...": "..."
    },
    "planning_data": [
      "..."
    ],
    "timeline_data": [
      "..."
    ],
    "timeline_handover_controls": {
      "...": "..."
    }
  }
}

Result:



HTTP 401 Unauthorized

The launcher recorded:



KICKOFF_FAILED_NO_RETRY
reason: HTTP_401: network request failed; no automatic retry performed
kickoff_post_attempted: true
automatic_retry_performed: false

The HTTP 401 response body was not exposed by the launcher, so I do not currently have a more detailed server response.

Important observation

I have not retried a stripped-down but otherwise valid three-required-field kickoff request, because if it succeeds it would create another production execution.

I stopped additional valid kickoff attempts intentionally to avoid duplicate or ambiguous executions.

What happens after the 401

  • No kickoff_id is returned
  • No execution is created
  • AMP showed 0 executions for the relevant period
  • Monthly execution usage did not increase
  • Crew Logs contained no corresponding execution logs
  • Endpoint Logs contained no corresponding request/execution logs
  • Deployment remained Crew is online

Transport checks already performed

I also tested the same Bearer Token and endpoint using:

  • PowerShell HTTP client
  • Python urllib
  • Python http.client
  • the exact Stage 4.2 Python transport class used by our launcher

Authenticated GET /inputs returned HTTP 200 with all of them.

A diagnostic POST /kickoff with incomplete inputs returned the expected HTTP 422 using the same Python transport.

Therefore this does not appear to be a simple token copy/paste or HTTP-client issue.

Question

Has anyone seen AMP/Ferry return HTTP 401 specifically after required-input validation succeeds and execution creation begins?

Is there an additional server-side authorization or execution-creation step that can return 401 even though:



GET /inputs + same Bearer Token -> 200
POST /kickoff with missing inputs -> 422
POST /kickoff with all production inputs -> 401

I cannot access Ferry, API-gateway, or execution-creation logs from the deployment UI.

Any guidance on the likely cause or the correct way to obtain the server-side rejection reason would be appreciated.

I can provide exact UTC timestamps and additional non-sensitive diagnostics if useful.

Thanks.

2

Update: this is still blocking production activation.

The Support chat has only returned repeated handoff acknowledgements so far, and no server-side Ferry / execution-creation findings have been provided.

We have made no further /kickoff attempts.

@Jason_T_CrewAI — could you please help route this to someone who can inspect the server-side execution-creation logs, or advise the correct escalation path?

Thank you.