TL;DR

I recently made changes to the content-automation repository, specifically in the craft_publisher.py file, to fix an issue with the documentIds parameter in the PUT /documents/move endpoint. This change ensures that documentIds is always an array, as required by the API. In this article, I'll dive into the technical details of the problem, the implementation, and the key takeaways from this experience.

The Problem

The issue arose from the PUT /documents/move endpoint expecting an array for the documentIds parameter, but the current implementation was passing a single value. This resulted in an error response from the API. The error message was not explicitly stated, but the API documentation confirmed that documentIds should be an array.

What I Tried First

Initially, I attempted to modify the craft_publisher.py file to pass the documentIds as a single value, assuming that the API would accept it. However, this approach failed, and I received an error response. Upon reviewing the API documentation, I realized that documentIds must be an array.

The Implementation

To fix the issue, I updated the craft_publisher.py file to ensure that documentIds is always an array. The relevant code change is shown below:

def _move_document(self, doc_id: str = "", document_id: str = "", folder_id: str = ""):
    try:
        r = self._client.put(
            f"{self._base}/documents/move",
            json={
                "documentIds": [document_id],  # Ensure documentIds is an array
                "folderId": folder_id
            }
        )
        # ... rest of the method implementation

In this updated code, I wrapped the document_id variable in a list, ensuring that documentIds is always an array.

Key Takeaway

The key takeaway from this experience is the importance of carefully reviewing API documentation and error responses. In this case, a simple mistake in the parameter format resulted in an error response. By paying attention to the API documentation and adjusting the implementation accordingly, I was able to resolve the issue.

What's Next

In the next phase of this project, I plan to investigate additional error handling and logging mechanisms to prevent similar issues in the future. This will involve reviewing the existing error handling implementation and identifying areas for improvement.

Conclusion

In conclusion, this technical deep-dive has demonstrated the importance of attention to detail when working with APIs. By sharing this experience, I hope to help other developers avoid similar pitfalls and ensure smoother integration with APIs.

Tags: #vibecoding #buildinpublic #apiintegration #python #craftapi

---

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-06-28

#playadev #buildinpublic